My Collection

This document is provided "as-is". Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. This document does not provide you with any legal rights to any intellectual property in any Microsoft product or product name. You may copy and use this document for your internal, reference purposes. You may modify this document for your internal, reference purposes. 2013 Microsoft. All rights reserved. Terms of Use (http://technet.microsoft.com/cc300389.aspx) | Trademarks (http://www.microsoft.com/library/toolbar/3.0/trademarks/en-us.mspx)

Table Of Contents
Chapter 1
Understanding Message Routing Understanding Transport Understanding Mailbox Getting Started With Exchange 2010

Chapter 1

Understanding Message Routing

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-04-12 The primary task of Hub Transport and Edge Transport servers in your organization is to route messages received from users and external sources to their ultimate destinations. This topic explains how Microsoft Exchange Server 2010 routes messages in your organization. Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents Overview of Message Routing in Exchange 2010 Routing Components Using Active Directory Sites for Routing Exchange 2010 Routing Tables Receiving Messages for Routing Routing Messages Rerouting and the Unreachable Queue

Overview of Message Routing in Exchange 2010

Routing decisions are made during message categorization. The categorizer is a component of the Microsoft Exchange Transport service that processes all incoming messages and determines what to do with the messages based on information about the intended recipients. The categorizer processes messages in several dependent phases and also uses other components of the Microsoft Exchange Transport service during message processing. After a message is received by an Exchange 2010 transport server, and after the preliminary processing that occurs during SMTP Receive is complete, the message is delivered to the Submission queue. Messages move from the Submission queue through the categorizer in the following phases:

1. Agent processing of submitted messages Some agent processing on the Hub Transport server occurs when the message is received for categorization. The agents that are applied during this phase include the optional Microsoft Forefront Protection for Exchange Server antivirus agent and the Journaling agent. 2. Recipient resolution During this phase, the recipient's e-mail address is resolved to determine whether the recipient has a mailbox in the Exchange organization or an external e-mail address. 3. Routing After information about the recipient is resolved, the routing component of the categorizer determines the ultimate destination for the message and the route to that destination, selects the next segment, or hop, for message relay, and resolves the next hop information to a list of physical servers and IP addresses. 4. Content conversion Before a message is relayed to its next hop, content conversion occurs so that the message is sent in a format that's readable by the recipient. Content conversion transforms e-mail messages from one format to another format for mail flow or storage, such as MAPI to MIME, or UUENCODE to base64 encoded, or for appropriate rendering that's specific to an e-mail client, such as HTML, rich text format (RTF), or plain text. 5. Agent processing of routed messages After the routing decisions for a particular message are made, the Transport Rules agent and the Journaling agent are applied on the Hub Transport server. The Journaling agent is applied both when the message is submitted and when it's routed so that any changes that are made to the message by the Transport Rules agent, for example, when it modifies a delivery address or applies a message-specific journaling requirement, don't bypass the Journaling agent. 6. Message packaging and DSN generation The final categorized message is assembled and moved to a delivery queue. A delivery status notification (DSN) may also be generated during this phase. Messages are next processed by SMTP Send, the store driver, delivery agents, or the foreign gateway connection handler. The component that's used depends on the ultimate destination. A delivery queue is dynamically generated for each hop. The messages are queued in these delivery queues after a routing decision is made. If a route can't be found for a recipient, the messages are queued to the Unreachable queue. The following figure shows how message processing occurs in the different routing phases and how messages are queued for delivery to the next hop destination. Routing context in mail flow

Return to top

Routing Components
To make routing decisions, Exchange 2010 must access configuration information that's stored in Active Directory. On an Edge Transport server, configuration information is stored in and accessed from the Active Directory Lightweight Directory Services (AD LDS) instance on the local server. Microsoft Windows and Exchange 2010 services work together to create mappings of the configuration data. These mappings are cached in routing tables. Exchange 2010 references these tables when it makes routing decisions. The cache is updated when the routing topology changes. The Exchange services that are used during message transport are common to both the Hub Transport server role and the Edge Transport server role. However, the Edge Transport server role doesn't cache information about the Active Directory topology. The following configuration and service components are important to message routing:

Active Directory sites An Active Directory site represents the routing boundary for Hub Transport servers. A Hub Transport server delivers directly to Mailbox servers, distribution group expansion servers, and to source servers for connectors in the local Active Directory site and to Edge Transport servers subscribed to that site. However, a Hub Transport server must relay messages to another Hub Transport server for recipients, expansion servers, and connectors that are located in remote Active Directory sites. The Hub Transport server role must be deployed in every Active Directory site that contains other Exchange 2010 server roles. Active Directory IP site links Active Directory IP site links define logical paths between Active Directory sites. Exchange 2010 references the IP site link objects to determine the least-cost routing path of remote Active Directory sites. Send connectors Send connectors are used for sending messages to other SMTP hosts. The address space configuration on Send connectors are used to make routing decisions. When a message is delivered to an external domain, the routing destination is typically a Send connector. An Exchange organization that accepts messages for more than one e-mail domain may decide to create Send connectors that are dedicated to each address space. For more information about Send connector selection for routing messages to external domains, see External Message Routing. Delivery agents Delivery agents are used to route messages to foreign systems that don't use SMTP protocol for message transfer. The address space and protocol configuration of delivery agents are used when making routing decisions. Foreign connectors Foreign connectors use drop directories to send messages to foreign systems that don't use SMTP protocol for message transfer. Exchange uses the configuration of Foreign connectors when making routing decisions. Routing groups Routing groups represent a routing boundary for Exchange Server 2003. If Exchange 2010 is deployed in an existing Exchange 2003 organization, routing must consider the location of servers within routing groups to deliver a message to a mailbox or a connector that resides on Exchange 2003. To implement compatibility with Exchange 2003, all computers running Exchange 2010 deployed in the organization belong to a single, global routing group. Routing group connectors Routing group connectors define logical paths between Exchange routing groups. If Exchange 2010 is deployed in an existing Exchange 2003 organization, messages are routed between server versions through routing group connectors. When the first Hub Transport server is deployed, the setup process prompts you to create a routing group connector from the global Exchange 2010 routing group to a legacy routing group. For more information about message routing in an environment where more than one version of Exchange is deployed, see Internal Message Routing. Microsoft Exchange Transport service The Microsoft Exchange Transport service is the SMTP provider for Exchange 2010 and controls every component of message processing, from SMTP IN to SMTP OUT. A series of configurable SMTP Receive agents are triggered at various SMTP events. The Microsoft Exchange Transport service enables these agents to process messages as they pass through SMTP transport and perform anti-spam, antivirus, and other tasks before messages are submitted to the categorizer. The Microsoft Exchange Transport service also uses the topology discovery module for Exchange topology discovery. Microsoft Exchange Active Directory Topology service The Microsoft Exchange Active Directory Topology service is responsible for locating the domain controllers and global catalog servers that Exchange 2010 can use to retrieve configuration and recipient data from Active Directory. The Microsoft Exchange Active Directory Topology service is also responsible for keeping Active Directory site affinity for an Exchange 2010 server up to date. Routing tables The routing tables hold the information that the routing component uses to make routing decisions. The routing table is composed of a map of topology components and their relationship to one another. DNS Exchange 2010 uses an enhanced Domain Name System (DNS) client, a component of the Microsoft Exchange Transport service, to resolve the next hop selection to a list of target server names. The standard DNS client is used to resolve that list of server names to IP addresses. Enhanced DNS also provides loadbalancing functionality for Exchange 2010 transport servers by using round robin. SMTP SMTP is used for communication when messages are relayed between SMTP servers. An SMTP server can be a Hub Transport server, Edge Transport server, Exchange 2003 server, or a smart host. A Hub Transport server uses remote procedure call (RPC) to deliver messages directly to Mailbox servers that have the same Active Directory site membership as the Hub Transport server. Return to top

Using Active Directory Sites for Routing

An Active Directory site is a logical configuration component that's based on the physical aspects of the network. The primary purpose for creating an Active Directory site is to define which subnets in the network are connected in a way that optimizes control of Active Directory replication traffic. The Active Directory site represents a routing boundary for Exchange 2010. Computers that have the Hub Transport server role installed make routing decisions based on the Active Directory site topology.

Determining Site Membership

By default, an Active Directory forest contains only one Active Directory site. The default name for this Active Directory site is Default-First-Site-Name. If no other Active Directory sites are created, all domain member computers in the forest are members of Default-First-Site-Name. You don't have to configure a subnet-to-site

association. If additional Active Directory sites are created, you must specify the subnets that are assigned to that Active Directory site. Each Active Directory site is associated with one or more IP subnets. An administrator assigns Active Directory site membership to computers that are configured as domain controllers and global catalog servers. Other domain member computers, such as Exchange servers, are assigned Active Directory site membership automatically when they're configured to use an IP address that's in an IP subnet that's associated with an Active Directory site. Computers that have the same Active Directory site membership are presumed to have good network connectivity. A server is always a member of a single Active Directory site. When an application can determine the Active Directory site membership of the computer where it's installed and of other computers in the forest, and then use that information to control communication flow, it's a site-aware application. When site-aware applications must use the services of another server, such as a domain controller or global catalog server, priority is given to the servers that have the same Active Directory site membership as the computer that's requesting those services. Exchange 2010 is a site-aware application and uses the Active Directory topology for message routing and to communicate with the services that are running on computers that have other Exchange 2010 server roles installed. The Active Directory site isn't only the routing boundary. It's also the service discovery boundary. Determining site membership for a domain member computer depends on a series of DNS queries to compare the local IP address to defined subnets and then determine the appropriate site membership association. To reduce the overhead that's associated with DNS queries, the Exchange 2010 Active Directory schema additions include the msExchServerSite attribute for the Exchange server object. The value of this attribute is the distinguished name of the Active Directory site of an Exchange server. This attribute is a property of each Exchange server object. When site membership affinity is stored as an attribute of the server object, the current topology can be read directly from Active Directory instead of relying on DNS queries and a site membership association is enabled for a non-domain computer, such as a subscribed Edge Transport server. The value for the msExchServerSite attribute is populated and kept up to date by the Microsoft Exchange Active Directory Topology service. When a Windows-based computer starts, the Net Logon service determines site membership for the computer. The Net Logon service uses that information to locate domain controllers that are located in the same Active Directory site as the local computer and then directs authorization and authentication requests to those servers. The Microsoft Exchange Active Directory Topology service uses the DsGetSiteName API call to retrieve the site membership value from the Net Logon service and writes the Active Directory site's distinguished name to the msExchServerSite attribute for the Exchange server object in Active Directory. The following table shows how an organization might define Active Directory sites. In this example, three Active Directory sites are defined, and each Active Directory site is associated with more than one IP subnet. Example of an Active Directory site-to-subnet association

Active Directory site name Site A

Associated IP subnets 192.168.1.0/24 192.168.2.0/24 192.168.3.0/24 192.168.4.0/24 192.168.5.0/24 192.168.6.0/24

Site B

Site C

If a server named HubTransportA has the IP address of 192.168.1.1, it's a member of Site A. By changing the IP address of a server, you may change its site membership. If you change the IP address of HubTransportA to 192.168.2.1, it won't change the server's Active Directory site membership because that subnet is also associated with Site A. However, if you move the server and the IP address changes to 192.168.3.1, the server would be considered a member of Site B. A change in site membership can also occur if you change the association of subnets to Active Directory sites. For example, if you remove the subnet 192.168.3.0 from association with Site B and associate it with Site A, the site membership of a server that has the IP address of 192.168.3.1 also changes to Site A. Whenever a change in site membership occurs, Exchange 2010 must update its configuration data so that the change is considered when Exchange 2010 makes routing decisions. Some latency occurs between the time that a change in an Active Directory site membership occurs and the topology change is fully propagated. The following communication must occur in the following order to propagate topology changes:

1. The change in site membership is written to a domain controller. The updated information replicates between the domain controllers in each Active Directory site in the forest. The time that's required for the change to propagate fully throughout the forest depends on the Active Directory replication topology and schedule as defined by site links. 2. The Net Logon service runs on all Windows-based computers and polls frequently for changes in Active Directory site membership. The Net Logon service polls at five-minute intervals. Therefore, the change is detected by the Net Logon service within five minutes of the local domain controller receiving the update. 3. The Microsoft Exchange Active Directory Topology service queries the Net Logon service at 15-minute intervals to determine the Active Directory site membership of the local Exchange server. If a change is detected, the Microsoft Exchange Active Directory Topology service updates the MsExchServerSite attribute. 4. The changed site attribute value of the Exchange server configuration object is then replicated throughout the organization. The Exchange servers in the organization detect this change. Then the routing tables are updated with the new Active Directory site membership attribute value. Some latency occurs between the time that an Active Directory site membership change takes effect and the time that the updated information is available to another Exchange 2010 server. For more information about how Exchange 2010 handles these types of configuration changes, see "Rerouting and the Unreachable Queue" later in this topic.

IP Site Links
Site links are logical paths between Active Directory sites. A site link object represents a set of sites that can communicate at a uniform cost through a specified intersite transport. Site links don't correspond to the actual path taken by network packets on the physical network. However, the cost assigned to the site link by the administrator typically relates to the underlying network reliability, speed, and available bandwidth. For example, the Active Directory administrator would assign a lower cost to a network connection with a speed of 100 megabits per second (Mbps) than to a network connection with a speed of 10 Mbps. By default, all site links are transitive. This means that if Site A has a link to Site B, and Site B has a link to Site C, Site A is transitively linked to Site C. The transitive link between Site A and Site C is also known as a site-link bridge. An Active Directory site link can be configured to use either IP or SMTP as the transport protocol for communication. An SMTP site link is limited in the types of data that can be replicated by using that protocol and is designed to provide a store and forward mechanism for replication between Active Directory sites that don't have

a reliable network link. An IP site link isn't limited in the types of data that can be replicated across it. Exchange 2010 uses only IP site links to determine its routing topology. The cost that's assigned to the IP site link will be considered by the routing component of Exchange 2010 when calculating a routing table. These costs are used to calculate the least-cost routing path to the ultimate destination for a message. Every Active Directory site must be associated with at least one IP site link. There is a single default IP site link named DEFAULTIPSITELINK. When you create an Active Directory site, you must associate that site to an IP site link. You can create additional IP site links to implement the desired topology, or you can associate every Active Directory site to the DEFAULTIPSITELINK. Each Active Directory site that's part of an IP site link can communicate directly with every other site in that link at a uniform cost. In the following figure, four Active Directory sites are configured in the forest. Every site has been associated with the DEFAULTIPSITELINK. Therefore, each Active Directory site communicates directly with every other site by using the same cost metric. More than one communication path is indicated, but only a single IP site link is defined. Full mesh topology with a single IP site link

In the following figure, four Active Directory sites are configured in the forest. In this topology, the administrator has configured IP site links to create a hub-and-spoke topology of Active Directory sites. Each spoke site can communicate directly with the central site, and the spoke sites can communicate with one another by using the transitive IP site links. Hub-and-spoke topology of Active Directory IP site links

It's important to note that Exchange uses site links only when determining the least-cost path, but will always try to deliver messages directly to the destination Hub Transport server. For example, if a user in Site B in the topology shown in the preceding figure sends a message to another user in Site C, the Hub Transport server in Site B will connect directly to the Hub Transport server in Site C. If you want to force messages to go through Site A, you must enable that site as a hub site. For more information about hub sites, see "Implementing Hub Sites" later in this topic. An Active Directory administrator implements the topology that best represents the connectivity and communication requirements of the forest. Because the same topology is used by Exchange 2010, you must make sure that the current topology supports efficient messaging communication. The default cost for a site link is 100. A valid site link cost can be any number from 1 through 99,999. If you specify redundant links, the link with the lowest cost assignment is always preferred. An Exchange organization administrator can assign an Exchange-specific cost to an IP site link. If an Exchange cost is assigned to an IP site link, it will be used by Exchange 2010. Otherwise, the Active Directory cost is used. For more information about how to set an Exchange cost on an IP site link, see "Controlling IP Site Link Costs" later in this topic. An administrator who has membership in the Enterprise Administrators group can create additional IP site links. For more information about Active Directory site configuration, see Designing the Site Topology.

Controlling IP Site Link Costs

Active Directory IP site links costs are based on relative network speed compared to all network connections in the WAN and are designed to produce a reliable and efficient replication topology. Therefore, in most cases, the existing IP site link costs should work well for Exchange 2010 message routing. However, if after documenting the existing Active Directory site and IP site link topology, you verify that the Active Directory IP site link costs and traffic flow patterns aren't optimal for Exchange 2010, you can make adjustments to the costs evaluated by Exchange. Changing the cost assigned to the IP site link by using Active Directory tools would impact the entire environment. Instead, use the Set-AdSiteLink cmdlet in the Exchange Management Shell to assign an Exchange-specific cost to the IP site link. For example, to set a different cost on the IP site link SITELINKAB for message routing purposes, run the following command in the Shell.

Set-AdSiteLink -Identity SITELINKAB -ExchangeCost 25

When an Exchange cost is assigned to an IP site link, the Exchange cost overrides the Active Directory cost for message routing purposes, and routing only considers the Exchange cost when it evaluates the least-cost routing path. Adjusting IP site link costs can be useful when the message routing topology has to diverge from the Active Directory replication topology. Exchange costs can be used to force all message routes to use a hub site. Exchange costs can also be used to control where messages are queued when communication to an Active

Directory site fails. The following figure shows an Active Directory topology with four sites. Topology with Exchange costs configured on IP site links

In the preceding figure, the network connection between Site C and Site D is a low bandwidth connection that's only used for Active Directory replication and shouldn't be used for message routing. However, the Active Directory IP site link costs cause that link to be included in the least-cost routing path from any other Active Directory site to Site D. Therefore, messages are delivered to the Site D queue in Site C. The Exchange administrator prefers that the least-cost routing path include Site B instead so that if Site D is unavailable, the messages will queue at Site B. Configuring a high Exchange cost on the IP site link between Site C and Site D prevents that IP site link from being included in the least-cost routing path to Site D. Exchange 2010 provides support for configuration of a maximum message size limit on an Active Directory IP site link. By default, Exchange 2010 doesn't impose a maximum message size limit on messages that are relayed between Hub Transport servers in different Active Directory sites. If you use the Set-AdSiteLink cmdlet to configure a maximum message size on an Active Directory IP site link, routing generates a non-delivery report (NDR) for any message that has a size larger than the maximum message size limit that's configured on any Active Directory site link in the least-cost routing path. This configuration is useful for restricting the size of messages that are sent to remote Active Directory sites that must communicate over low-bandwidth connections. For more information, see Understanding Message Size Limits.

Implementing Hub Sites

In your Exchange organization, you may have to force all message delivery to be relayed through a particular Active Directory site. In this scenario, connectivity may prevent direct SMTP relay between sites. Therefore, messages must be relayed through an interim site before they're sent to their destination. Because of an Exchange organization's internal policies, an administrator may also want to relay all messages through a particular site. You can use Shell cmdlets to designate an Active Directory site as a hub site. By designating an Active Directory site as a hub site, you cause additional overall overhead because more servers are involved in message delivery. For example, consider a message that's sent from Site A to Site E. If the least-cost routing path is Site A-Site B-Site C-Site D-Site E, and you designate Site C as a hub site, the message is relayed from Site A to Site C and then relayed from Site C to Site E. You use the Set-AdSite cmdlet to specify an Active Directory site as a hub site. Whenever a hub site exists along the least-cost routing path for message delivery, the messages queue and are processed by the Hub Transport servers in the hub site before they're relayed to their ultimate destination. After the least-cost routing path is chosen, routing determines whether there's a hub site along that routing path. If a hub site is configured, messages stop at a Hub Transport server in the hub site before they're relayed to the target destination. If there's more than one hub site along the least-cost routing path, messages stop at each hub site along the routing path. This variation to direct relay routing only is in effect when the hub site is located along the least-cost routing path. The following figure shows the correct use of a hub site. In this diagram, Site B is configured as a hub site. Messages that are relayed from Site A to Site D are relayed to Site B before they're delivered to Site D. Message delivery with a hub site

The following figure shows how IP site link costs affect routing to a hub site. In this scenario, Site B has been designated as a hub site. However, because it doesn't

exist along the least-cost routing path between any other sites, queuing at Site B before delivery to the destination doesn't occur. An Active Directory site is never used as a hub site if it isn't on the least-cost routing path between two other sites. Misconfigured hub site

You can configure any Active Directory site as a hub site. However, for this configuration to work correctly, you must have deployed at least one Hub Transport server in the hub site.

Topology Discovery
The Exchange 2010 topology relies on the Active Directory site topology and doesn't have its own configuration. The Active Directory topology is made available to Exchange 2010 by the following required elements:

The Microsoft Exchange Active Directory Topology service The topology discovery module inside the Microsoft Exchange Transport service The Microsoft Exchange Active Directory Topology service runs on all Exchange 2010 server roles, except the Edge Transport server role. These Exchange 2010 servers use the Microsoft Exchange Active Directory Topology service to discover the domain controllers and global catalog servers that can be used by the Exchange servers to read and write Active Directory data. Exchange 2010 binds to the identified directory servers whenever Exchange has to read from or write to Active Directory. The topology discovery module is part of the Microsoft Exchange Transport service and provides information about the Active Directory topology to Exchange servers. This API discovers the Exchange servers and roles in the organization and determines their relationship to the Active Directory configuration objects. Configuration data is retrieved from Active Directory and then cached so that it can be accessed by the Exchange services that are running on that computer. The topology discovery module performs the following steps to generate an Exchange routing topology:

1. Data is read from Active Directory. All the following objects are retrieved: Active Directory sites. IP site links. All Exchange servers. This includes information about the Exchange 2010 server roles deployed on those servers. 2. The data that's retrieved in step 1 is used to create the initial topology and to begin linking and mapping the related configuration objects. 3. Exchange servers are matched to Active Directory sites by retrieving the site attribute value from the Exchange server object that's stored in Active Directory. 4. Routing tables are updated with the collection of information retrieved. This process makes every Exchange 2010 server aware of the other Exchange servers in the organization and of how close the Exchange servers are to one another. Return to top

Exchange 2010 Routing Tables

When the Microsoft Exchange Transport service starts, it calculates a set of routing tables that's based on the snapshot of information that's retrieved from Active Directory or, on an Edge Transport server, from AD LDS. The configuration information that's stored in AD LDS includes available connectors and accepted domains, but doesn't include topology data. The routing component refers to the routing tables to determine how to route messages to recipients. When configuration changes are made, the routing tables are rebuilt. The new routing tables are used to route new incoming messages. Messages in remote delivery queues are also rerouted if the routing component determines that they're affected by the configuration changes. For more information about message rerouting, see "Rerouting and the Unreachable Queue" later in this topic. The following configuration data is retrieved from Active Directory and made available to the routing component of Hub Transport servers:

Active Directory sites Active Directory IP site links Exchange servers and their relationship to Active Directory sites SMTP connectors Non-SMTP connectors Note: Non-SMTP connectors include Exchange 2010 delivery agent connectors, Foreign connectors, and in coexistence scenarios, any non-SMTP connectors hosted

by Exchange 2003. Routing groups Routing group connectors Mailbox stores (private message databases (MDBs)) Public folder stores (public MDBs) Public folder hierarchies Based on this data, the routing component of the Microsoft Exchange Transport service populates routing tables to help streamline routing decisions. The routing table correlates the data to create a topology map. This topology map contains the following elements:

Linked connectors map This map correlates the identifiers of Receive connectors on the local server to the linked Send connector. Server map All Exchange 2010 and Exchange 2007 Hub Transport servers, Edge Transport servers, Mailbox servers, and Exchange 2003 servers in the organization are contained in the server map. This map correlates the distinguished name of each Exchange server to server routing data. This includes the total cost to reach that server. Legacy server map All Exchange Server 2007 Hub Transport servers, Edge Transport servers, Mailbox servers, and Exchange 2003 servers in the organization are contained in the legacy server map. This map correlates the legacy distinguished name of each Exchange server to server routing data. This includes the total cost to reach that server. This map supports store override functionality. Store override functionality is specific to public folders. For more information, see "Routing to Public Folders" in Internal Message Routing. MDB map All MDBs in the organization are contained in the MDB map. This map correlates the distinguished name of each MDB to server routing data. This includes the total cost to reach that server. Active Directory site map This map correlates each Active Directory site to a structure that contains the least-cost routing path from the local site to every other site. The map includes any hub sites along the least-cost routing path. Each routing path hop also identifies all Hub Transport servers in that site that will be used by the enhanced DNS component. Routing groups map This map associates the total cost and first hop routing group connector for the least-cost routing path from the Exchange 2010 routing group to each legacy routing group. Send connectors map This map identifies the Send connectors configured in the organization and the source servers for each connector. The routing tables are built every time that a transport server is started and recalculated when configuration changes are received. Configuration changes can be detected in any of the following ways:

Active Directory change notifications There is a delay between the time that a notification is received and the time that the change is written to the routing tables. This delay lets the routing component batch the changes and process more than one change in a single operation. By default, each notification causes the routing component to delay processing by five seconds. For example, if five notifications are received exactly one second after the previous notification, routing delays processing the change for a total of nine seconds. Configuration reloading caused by service control commands The routing component reloads the configuration data when the Microsoft Exchange Transport service is restarted. Periodic reload to track changes that aren't supported by Active Directory notifications By default, routing will periodically reload the configuration data to make sure that all changes are tracked. The configuration reload occurs at six-hour intervals. The information in the routing tables is logged to routing logs. By default, these logs are located in the C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\Routing folder. A new log is generated every time that the routing tables are calculated. If for some reason the Hub Transport server is unable to contact Active Directory, routing continues to make routing decisions based on the currently cached data, even though that data may not be up to date. For more information, see Understanding Routing Table Logging. Return to top

Receiving Messages for Routing

A message can arrive at a Hub Transport server in any of the following ways:

E-mail is received from an Internet-facing SMTP server for delivery to a recipient in the Exchange organization or to a recipient in an internal relay accepted domain. E-mail is received from another Hub Transport server in the Exchange organization for delivery to a recipient mailbox that's located on a Mailbox server in that Active Directory site. E-mail is received from SMTP clients. These are typically POP3 or IMAP4 users that may exist in your environment. E-mail is received from Pickup and Replay directories on a Hub Transport server. These directories are typically used by Foreign connectors to transmit messages to your Exchange infrastructure. E-mail is retrieved from an Exchange 2010 Mailbox server by the Hub Transport server. E-mail is received from an Exchange 2007 or Exchange 2003 server for delivery to a recipient mailbox that's located on an Exchange 2010 Mailbox server. Processing of all e-mail that's received by a Hub Transport server for categorization begins in the Submission queue.

Receiving Messages from Edge Transport Servers, Other Exchange Hub Transport Servers, and SMTP Clients
In this scenario, messages are received from Edge Transport servers, Hub Transport servers, or other third-party SMTP hosts by using standard SMTP connections. The remote host initiates an SMTP connection and transfers the messages to the Hub Transport server. Hub Transport servers use Receive connectors for accepting incoming SMTP connections. Each Hub Transport server has two Receive connectors created during setup. One of these connectors is used to receive authenticated SMTP connections from other Exchange servers. The second one is used to receive SMTP connections from SMTP clients used by POP3 or IMAP4 users in your organization. These two Receive connectors have different permissions configured that are appropriate for their intended use. To learn more about Receive connectors, see Understanding Receive Connectors. By default, Hub Transport servers don't accept unauthenticated anonymous connections. If you need to enable this functionality, we recommend that you create a separate Receive connector to handle the anonymous connections. For more information, see Allow Anonymous Relay on a Receive Connector.

Collecting Messages from Pickup and Replay Directories

Messaging systems that don't use SMTP as the transfer protocol can be connected to your Exchange organization using Foreign connectors. When a message is sent to an Exchange user from a remote system, the Foreign connector writes that message to a special directory on the Hub Transport server called the Pickup directory.

The Hub Transport server periodically checks the Pickup directory for new messages. When it detects a new message, the Hub Transport server then converts the message to an Exchange e-mail message and routes it as a regular message. To learn more about how the Pickup and Replay directories are used, see Understanding the Pickup and Replay Directories.

Retrieving Messages from a Mailbox Server

In this scenario, the Microsoft Exchange Mail Submission service that runs on Mailbox servers notifies a Hub Transport server that's located in the same Active Directory site that messages are ready for retrieval from a sender's outbox. Each Mailbox server maintains a list of Hub Transport servers that are located in the same Active Directory site. This list of Hub Transport servers is known as the submission server list. The server discovery process repeats every ten minutes to keep the list up to date. If more than one Hub Transport server is located in the same Active Directory site as the Mailbox server that's submitting a notification that mail is ready for retrieval, the following process is used to select the server:

If the local Mailbox server is also running the Hub Transport server role and it is not participating in a database availability group (DAG), the local server is notified. If the local Microsoft Exchange Transport service isn't running or the local Hub Transport server can't process new mail submissions because of back pressure, another available Hub Transport server is notified. For more information about back pressure, see Understanding Back Pressure. If the local Mailbox server is also running the Hub Transport server role and is also participating in a DAG, it first tries to notify any Hub Transport server in the site before notifying the local Hub Transport server. This is done to avoid having redundant copies of messages on the same server hardware. To learn more about coexisting Mailbox and Hub Transport server roles when using DAGs, see Hub Transport and Mailbox Server Roles Coexistence When Using DAGs. If the local Mailbox server isn't running the Hub Transport server role, notifications are load balanced among Hub Transport servers by using round robin. If the selected Hub Transport server can't be contacted, the Microsoft Exchange Mail Submission service fails over to a different Hub Transport server in the same Active Directory site. The failing server is marked as inactive, and the next Hub Transport server in the submission server list is selected. If no Hub Transport servers in the local Active Directory site are available, the submission server list is empty. In this case, an event is logged and mail submission notifications are temporarily stopped. Hub Transport servers that are marked as inactive are retried after five minutes. By default, the Microsoft Exchange Mail Submission service load balances notification events across the Hub Transport servers in a site so that each Hub Transport server receives an equal distribution of notification events to process. In some circumstances, providing an equal distribution may not be an optimal solution. Not all Hub Transport servers have the same capacity, and some messages require additional processing. For example, a message that has a large attachment or many recipients takes longer for a Hub Transport server to process than a small message that's addressed to only one recipient. If you want to create a static list of Hub Transport servers that a Mailbox server should notify, you can use the Set-MailboxServer cmdlet in the Shell. Use the SubmissionServerOverrideList parameter to specify a list of Hub Transport servers that the local Mailbox server will notify when it has mail for retrieval. For more information about how to configure this setting, see Set-MailboxServer. After a Hub Transport server receives a mail submission notification from a Mailbox server, it uses the store driver to retrieve the message from the mailbox database and put it in the Submission queue on the Hub Transport server. The transfer of the message from the Mailbox server to the Hub Transport server happens by using Exchange RPC.

Receiving Messages from Legacy Exchange Servers

Due to the changes made to the Exchange Server Object (XSO) model in Exchange 2010, Exchange 2010 Hub Transport servers can't pick up messages from and deliver messages to Exchange 2007 Mailbox servers. Similarly Exchange 2007 Hub Transport servers can't communicate with Exchange 2010 Mailbox servers. All messages sent from Exchange 2007 recipients are first picked up from the Mailbox servers by Exchange 2007 Hub Transport servers and are then relayed to Exchange 2010 Hub Transport servers. To learn more about message routing when coexisting with Exchange 2007, see Upgrade from Exchange 2007 Transport. As opposed to Active Directory sites, Exchange 2003 uses routing groups to route messages. Routing groups are connected to each other using routing group connectors. To support coexistence between these two routing topologies, all Exchange 2010 servers are automatically added to a single routing group when Exchange 2010 is installed in an Exchange 2003 organization. All messages that originate on Exchange 2003 mailboxes are delivered to the Exchange 2010 environment through the routing group connectors between the Exchange 2010 routing group and the Exchange 2003 routing groups. To learn more about message routing when coexisting with Exchange 2003, see Upgrade from Exchange 2003 Transport. Return to top

Routing Messages
After a Hub Transport server or an Edge Transport server receives a message, it determines the ultimate destination and uses the Exchange topology and connector configurations to determine the least-cost routing path. After the routing path is determined, the message is delivered to the next hop on the routing path. Although this topic explains how Exchange makes routing decisions in general, the following two topics provide additional information about specific routing scenarios. The internal message routing topic discusses message delivery to Mailbox servers, public folders, and legacy servers. The external message routing topic discusses routing messages to recipients that are outside your Exchange organization. The topic also discusses the roles of Send connectors, delivery agent connectors, and Foreign connectors.

Internal Message Routing External Message Routing

Determining the Ultimate Destination

The previous section described the various sources from which a Hub Transport server can receive messages. When a message is received by a Hub Transport server, the message must be categorized. The first phase of message categorization is recipient resolution. After the recipient has been resolved, the ultimate destination can be determined. The next phase, routing, determines how to best reach that destination. A single, deterministic route is selected. That route isn't recalculated unless the routing configuration changes. From the perspective of the sending server, each delivery queue represents the destination for a particular message. When the Hub Transport server or Edge Transport server selects the destination for a message, the destination is stamped on the recipient as the NextHopSolutionKey attribute. If a single message is being sent to more than one recipient, each recipient has the NextHopSolutionKey attribute. The receiving server also performs message categorization and queues the

message for delivery. After a message is queued, you can examine the delivery type for a particular queue to determine whether a message will be relayed again when it reaches the next hop destination. The destination for a message can be classified as one of the following delivery types:

DNS connector delivery The messages are queued for delivery to an external recipient by using an SMTP Send connector for which the local server is a source server. The connector is configured to use DNS to resolve the recipient addresses. Smart host connector delivery The messages are queued for delivery to an external recipient by using an SMTP Send connector for which the local server is a source server. The connector is configured to use a smart host for delivery. SMTP relay in an Active Directory site to an Edge Transport server The messages are queued for delivery to an external recipient by using an SMTP Send connector for which the source server is an Edge Transport server that's subscribed to the local Active Directory site. SMTP relay in an Active Directory site to a Hub Transport server The messages are queued for delivery to a Hub Transport server that's located in the same Active Directory site as the local server. The destination server can be an Exchange 2007 Hub Transport server, the source server for a Send connector, a delivery agent connector or Foreign connector, the source server of a routing group connector, or a distribution group expansion server. SMTP relay to a remote Active Directory site The messages are queued for delivery to a Hub Transport server that's located in a remote Active Directory site. The ultimate destination server in the remote Active Directory site can be any of the following: The source server for a connector that's configured to transport messages for external recipients The source server for a routing group connector A distribution group expansion server A Mailbox server that's located in the remote Active Directory site The messages are delivered to one of the Hub Transport servers in the destination site. The receiving server relays the message within the Active Directory site if it's necessary. SMTP relay to a legacy routing group The messages are queued for delivery to the first hop routing group connector used to reach an Exchange 2003 routing group. The ultimate destination server can be any of the following: The source server for a connector An expansion server An Exchange 2003 bridgehead server that delivers messages addressed to mailbox recipients that are located in the routing group MAPI delivery The messages are queued for delivery to a recipient's mailbox, a public folder, or a public folder store that's located on a Mailbox server that's located in the local Active Directory site. Non-SMTP gateway delivery The messages are queued for delivery to an external recipient by using a delivery agent connector or Foreign connector for which the local server is a source server. This delivery type is used only when the messages are being delivered to delivery agent connectors or the Foreign connector drop directory on the local server. Unreachable A route to the recipient couldn't be determined and the messages are located in the Unreachable queue.

Determining the Least-Cost Routing Path

The least-cost routing path to the remote Active Directory site is determined by the calculation of all the costs assigned to the Active Directory IP site links that exist between the two sites. The links are bridged, and a direct connection occurs. Exchange 2010 Hub Transport servers always select a single, deterministic least-cost routing path. Availability of the underlying connection or destination server is never a consideration in routing path selection, and no alternative routing path is considered. The least-cost routing path calculation is used to determine a backoff path when message delivery to the next hop fails. In Exchange 2010, backoff is a mechanism used to deliver messages at an interim hop along the least-cost routing path when direct relay fails for any reason, such as network issues or servers going offline. The routing component tries to deliver messages as close to the destination as possible by backing off, hop by hop, along the least-cost routing path until a connection is made. First, a connection attempt is made to each Hub Transport server in the destination Active Directory site. If no Hub Transport servers in the Active Directory site respond, the least-cost routing path is checked to determine how to start backing off from the delivery site. The goal is to deliver the message as close as possible to the destination and queue it at a Hub Transport server in that Active Directory site. Depending on the individual message routing scenario, the following factors may influence the selection of a least-cost routing path:

Linked connectors If the Receive connector that the message is received on is linked to a Send connector, messages are routed to that Send connector regardless of cost. This configuration always takes precedence. The cost assigned to the IP site links and routing group connectors that must be traversed to reach the destination If more than one routing path exists between a source server and a destination server, the routing path with the lowest aggregate cost is selected. The address space assigned to a Send connector The Send connector with the most specific address space match to the destination is selected. The cost assigned to the address space configured on a Send connector If more than one Send connector is assigned the same address space, the routing component compares the cost assigned to the address space. The Send connector with the lowest cost is selected. Connector scope A connector may be limited to use by Exchange 2010 servers that are located in the same Active Directory site as the source transport servers for the connector. In earlier versions of Exchange, the connector scope could be limited to servers that have the same routing group membership. Message size restrictions The message size constraint specified on a connector must be larger than the size of the message being routed. Connectors with a message size restriction that's less than the size of the message are eliminated from routing consideration. The proximity of the destination to the sending server Routing will prefer the server that's closest, in this order: local server, server in the same Active Directory site, or server in a remote Active Directory site or routing group. The name assigned to an Active Directory site If more than one routing path results in the same aggregate cost, the routing component makes an alphanumeric comparison of the name of the Active Directory sites that precede the target site along each routing path. The routing path where the Active Directory site nearest to the destination is lowest in alphanumeric order is used. The name assigned to a routing group connector If more than one routing path results in the same aggregate cost, the routing component makes an alphanumeric comparison of the name of the routing group connectors that come before the target destination along each routing path. The routing path where the routing group connector nearest to the destination is lowest in alphanumeric order is used. The connector state The Exchange 2010 routing component only considers enabled connectors when it calculates the routing path. However, earlier versions of Exchange don't consider connector state. The following logic is used to select the routing path:

1. First, calculate the least-cost routing path by adding the cost of the IP site links and of any routing group connectors that must be traversed to reach the destination. If the destination is a connector, the cost assigned to the address space is added to the cost to reach the selected connector. If multiple routing paths are possible, only the routing path with the lowest aggregate cost is used. 2. If more than one routing path has the same aggregate cost, the number of hops in each path is evaluated and the routing path with the least number of hops is used. 3. If more than one routing path is still available, the name assigned to the Active Directory sites or routing group connectors before the destination are considered. The routing path where the Active Directory site nearest the destination is lowest in alphanumeric order is used. If the site nearest the destination is the same for all routing paths being evaluated, an earlier site name is considered. The following figure shows the routing topology for an Exchange organization. This topology is used in the following examples to demonstrate the logic used by the

routing algorithm to select the least-cost routing path. Exchange 2010 routing topology

Example 1 A message that's being relayed from Site A to Site D can follow two possible routing paths: Site A-Site B-Site D and Site A-Site C-Site D. The costs assigned to the IP site links in each routing path are added to determine the total cost to route the message. In this example, the routing path Site A-Site B-Site D has an aggregate cost of 20. The routing path Site A-Site C-Site D has an aggregate cost of 10. Routing selects path Site A-Site C-Site D. Example 2 A message is being relayed from Site B to Site D. There are three possible routing paths: Site B-Site D with a cost of 15, Site B-Site E-Site C-Site D with a cost of 15, and Site B-Site A-Site C-Site D with a cost of 15. Because more than one routing path results in the same cost, routing selects the routing path Site B-Site D. This has the least number of hops. Example 3 A message is being relayed from Site A to Site E. There are two possible routing paths: Site A-Site B-Site E with a cost of 10, and Site A-Site C-Site E with a cost of 10. Both routing paths have the same cost and same number of hops. The alphanumeric order of the Active Directory sites immediately before Site E is compared. Site B has a lower alphanumeric value than Site C. Therefore, routing selects the routing path Site A-Site B-Site E. After the least-cost routing path has been determined, the Exchange 2010 routing component doesn't consider alternative routing paths.

Next Hop Selection

Exchange 2010 Hub Transport servers don't relay to each Active Directory site along the least-cost routing path. After the routing path is determined, the message is relayed directly from the source server to the next hop. The next hop selection tries to deliver the messages as close as possible to the ultimate destination. Additional intrasite relay may be required to arrive at the ultimate destination. When routing to legacy routing groups, direct relay to the Active Directory site where the source server for the first hop routing group connector resides occurs. After the message is relayed to the legacy environment, standard legacy routing occurs. The following figure shows a simple Exchange topology and illustrates many of the Exchange routing components. Exchange topology and routing components

Using the preceding figure as a reference, a message that's sent from Mailbox1 in Site A, to the external recipient joe@contoso.com is processed as follows:

1. The Microsoft Exchange Mailbox Submission service that's running on Mailbox1 notifies an Exchange 2010 Hub Transport server that's located in the same Active Directory site of the new mail item for transport. 2. Using RPC, the store driver component on an Exchange 2010 Hub Transport server in the same Active Directory site retrieves the message and puts it in the Submission queue on the local server. 3. From the Submission queue, the message moves through categorization. The categorizer first performs recipient resolution and determines that

joe@contoso.com is an external recipient. 4. The routing component selects the best connector through which to route the message and calculates the least-cost routing path to that connector. In this example, a Send connector has the address space *.contoso.com and is the connector selected by the routing component. All the source servers for this Send connector are located in Site B. 5. The routing component determines the next hop required to reach a source server for the Send connector. The Hub Transport server in Site A queues the message for SMTP delivery to Site B. 6. If the receiving server in Site B is a source server for the Send connector, it queues the message for delivery to that Send connector. If the receiving server isn't a source server for the *.contoso.com Send connector, the message is relayed by using SMTP to a Hub Transport server in Site B that's the source server for the connector. The following table provides additional examples of the next hop selection for several recipients based on the topology shown in the preceding figure. It isn't a complete list of all routing possibilities. It simply provides examples that are most common in a topology like the one shown in the preceding figure. Examples of next hop selection in the preceding figure

Receiving server Hub1 Hub1 Hub1 Hub1 Hub1 Hub3 Hub4 Hub4 Hub4 Hub4 Edge1

Ultimate destination Mailbox1 Mailbox2 Mailbox3 Mailbox4 Recipient@fourthcoffee.com Mailbox1 Mailbox1 Mailbox4 Recipient@contoso.com Recipient@fourthcoffee.com Recipient@fourthcoffee.com

Next hop Mailbox1 Hub3 Site B Routing group connector Edge1 Hub1 or Hub2 Site A Site A Contoso SMTP Host Site A Fourth Coffee SMTP Host

Queue delivery type MAPI delivery SMTP relay in an Active Directory site SMTP relay to a remote Active Directory site SMTP relay to a legacy routing group SMTP relay to Edge Transport SMTP relay in an Active Directory site SMTP relay to a remote Active Directory site SMTP relay to a remote Active Directory site Smart host delivery SMTP relay to a remote Active Directory site DNS delivery

After the least-cost routing path has been calculated and the next hop destination has been chosen, Exchange 2010 routing tries to relay the message directly to the destination, unless a hub site is configured along the least-cost routing path.

Queue at Point of Failure

The least-cost routing path calculation is used to determine a backoff path when message delivery to the next hop fails. Exchange 2010 tries to deliver messages as close to the destination as possible by backing off, hop by hop, along the least-cost routing path until a connection is made. This behavior is known as queue at point of failure. When the messages are queued at the point in the delivery path where communication failed, it not only speeds up delivery after the problem is resolved, but it will also help you determine why the message delivery failed. In the topology shown in the following figure, if a message is being delivered from Site A to Site D, the least-cost routing path may be Site A-Site B-Site C-Site D. Delivery will first be tried directly from Site A to Site D. If no Hub Transport server in Site D responds, delivery will be tried to the Hub Transport servers in Site C. This process continues until a Hub Transport server accepts the message. If all intermediate sites are unavailable, the message will be queued at the source site. If the message is queued in Site C, you can start investigating the failure at the Hub Transport servers in Site D or the network connectivity between Site C and Site D. Queue at point of failure

When the message is queued at the point of failure, the queue is put in a retry state and delivery attempts continue based on the message retry intervals until delivery succeeds or the message expires. The queue is automatically resubmitted for categorization again after a default interval of 12 hours. Queues that have a connector as the next hop destination aren't automatically resubmitted unless a configuration change that causes resubmission occurs. For more information, see Message Rerouting and the Unreachable Queue. You can use the Mail Flow Troubleshooter to help diagnose problems with mail flow. This tool is a component of the Microsoft Exchange Troubleshooting Assistant and can be run from the Toolbox of the Exchange Management Console. In more complex topologies, the least-cost routing path between two Active Directory sites can contain many intermediate Active Directory sites. If a network issue occurs somewhere early along the routing path, it may be too inefficient to back off site by site from the end and try to deliver to every one of the intermediate sites. If the routing path is longer than four hops, binary backoff is implemented until four or fewer sites are remaining. Binary backoff means that the next connection attempt is made at the halfway point in the routing path. For example, if the least-cost routing path from Active Directory Site A to Site G is A - B - C - D - E - F - G and the network failure occurs at the link between Site B and Site C, the first connection attempt is made to all Hub Transport servers in Site G. When the connection attempt fails, the next attempt is made to all Hub Transport servers in Site D. This is halfway to Site G. When that connection attempt fails, connection attempts are

made to Site C, and Site B because they're closer than four links to the source site. The message will eventually be queued on a Hub Transport server in Site B until the B-C link connectivity is restored.

Delayed Fan-Out
A single e-mail message can be addressed to more than one recipient. These recipients may have internal mailboxes, or they may be external recipients. To route a single message to more than one recipient, the following steps occur:

1. Recipient resolution Each recipient of the message is resolved to a delivery destination. 2. Routing The least-cost routing path for each recipient is determined. This includes whether a hub site is configured. 3. Message splitting To route the message to recipients that have different delivery locations, the message must be split into multiple copies. After each recipient has been resolved and a routing path to each delivery destination is determined, Exchange 2010 compares the routing path for each recipient. To preserve bandwidth, the bifurcation, or splitting of the message into multiple copies, doesn't occur until a fork in the routing path is encountered. For example, if multiple recipients of a single message share part or all of the least-cost routing path, a single copy of the message is sent until the message reaches the point in the routing path where a fork occurs. When the divergence in routing paths occurs, the message splits to create a separate copy for each recipient. In the following figure, a single message is sent from Site A to recipients in Site C, Site D, and Site E. The least-cost routing path is shared until the message reaches Site B. In this scenario, a single copy of the message that contains all recipients is relayed to Site B. This represents the first fork in the routing path. From Site B, a single message copy is routed to the recipient in Site D, and a single copy is relayed to Site C. In Site C, the message splits again. A copy of the message is delivered to the recipient in Site C. And, a copy of the message is relayed to Site E for delivery to the recipient in that site. Delayed message fan-out

Return to top

Rerouting and the Unreachable Queue

If routing is unable to determine a route for a valid recipient for any reason, the messages are put in the Unreachable queue. Messages in this queue are rerouted when configuration changes are processed and routing tables are recalculated. Messages aren't rerouted in the following scenarios. Instead, an NDR is returned to the sender. The following scenarios result in a message being routed to the Unreachable queue:

The recipient is a non-SMTP address and a matching connector for the address space can't be found. The message doesn't meet the message size restrictions of any matching connector. Not all configuration changes require resubmission of the messages in the queue. For example, a change to the list of smart hosts for a connector doesn't cause messages to be rerouted. For more information about how messages are rerouted, see Message Rerouting and the Unreachable Queue. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

External Message Routing

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-12-07 Microsoft Exchange Server 2010 handles the routing of messages to external recipients. An external recipient is any message recipient that doesn't have a mailbox in the Exchange organization. Exchange uses Send connectors to route messages to external SMTP domains. If the external recipient isn't on an SMTP messaging system, a Delivery Agent connector or a Foreign connector is used instead. For more information about how Exchange makes routing decisions, see Understanding Message Routing. Looking for management tasks related to message routing? See Managing Message Routing. Contents Send Connectors Delivery Agent Connectors Foreign Connectors Connector Considerations Selecting the Routing Path to an External Recipient Routing Examples

Send Connectors

To route messages to external SMTP domains, you must configure at least one Send connector to relay messages to the Internet. You can configure a Send connector and define the address space as the asterisk (*) wildcard character. The * character indicates that the Send connector can be used to relay messages to all external SMTP addresses. You can also configure Send connectors to relay messages to specific address spaces when Send connector restrictions, such as message size, vary for those external domains. When you configure a Send connector, you must select at least one source server for that Send connector. The source servers are the transport servers associated with that connector to handle message delivery. The source server for a Send connector can be a Hub Transport server, an Edge Transport server, or an Edge server subscribed to an Active Directory site. You can configure more than one source server for a Send connector to provide load balancing and fault tolerance for the address spaces defined on that Send connector. However, each Exchange 2010 source transport server you specify must be in the same Active Directory site. For more information about how to configure your Exchange organization to send and receive Internet e-mail, see Managing Message Routing. When Exchange is processing a message sent to an external recipient, the routing component of the Microsoft Exchange Transport service must select the best Send connector through which to route the message, and then calculate the least cost routing path to reach that Send connector. To learn more about Send connectors, see Understanding Send Connectors. Return to top

Delivery Agent Connectors

Delivery Agent connectors are used to route messages addressed to messaging systems that don't use SMTP. When a message is routed to a Delivery Agent connector, the associated delivery agent performs the content conversion and message delivery. Delivery Agent connectors allow queue management for non-SMTP messages, thereby eliminating the need for storing messages on the file system in the Drop and Pickup directories. For more information, see Understanding Delivery Agents. Return to top

Foreign Connectors
Foreign connectors are used to send messages to third-party messaging systems. Each Foreign connector uses a Drop directory configured on the source Hub Transport servers for receiving messages. The foreign gateway server must be configured to obtain messages from the Drop directory specified for that Foreign connector. For more information about Foreign connectors, see Understanding Foreign Connectors. Return to top

Connector Considerations
Restrictions applied to the connectors may eliminate a specific connector from routing consideration. The following configuration options on connectors can determine whether those connectors are considered when making routing decisions. For more information about configuring connectors, see Managing Connectors.

Connector State
You can disable and enable any connector in your organization. If a connector is disabled, it's not considered when routing messages. For example, if an Exchange 2010 Send connector is disabled, messages aren't routed to that connector. Note: Exchange Server 2003 doesn't detect the disabled state of connectors. Therefore, if Exchange 2003 is deployed in the same organization, it may route to that connector.

Connector Scope
Routing only considers connectors in scope for the sending server. By default, no scope limitation is applied to connectors, and they are available to all Hub Transport servers in the organization. However, you can specify a local scope for a connector. If you configure a connector as scoped, the availability of that connector is limited to Hub Transport servers located in the same Active Directory site as the source servers for the connector. Scoped connectors aren't considered when routing by Hub Transport servers in other Active Directory sites.

Address Space
The address space for a connector specifies the following:

Recipient domains to which this connector routes e-mail Address space type Cost assigned to the address space for that connector When you create a Send connector, the address space type is always configured as SMTP by default. Even though you can also specify a non-SMTP address space for a Send connector, the messages are still sent using SMTP. If you need to use a different transport protocol for transmitting messages to their destination, you must use a Delivery Agent connector or a Foreign connector. When the Microsoft Exchange Transport service selects a connector for routing, it only considers connectors that have a matching address space for the destination domain. You can use the wildcard character * in an address space to indicate all domains, all domains that have a particular top-level domain, such as *.com, or a second-level domain and all its subdomains, such as *.contoso.com. When you configure a connector for a particular domain, e-mail sent to that domain is always routed through that connector. If more than one connector matches the address space for the destination recipient domain, the connector with the more precise address match is selected. For example, if Send connector C1 is configured to have the address space *.contoso.com and Send connector C2 is configured to have the address space northamerica.contoso.com, e-mail addressed to user@europe.subdomain.contoso.com is routed to Send connector C1 and e-mail addressed to user@northamerica.contoso.com is routed to Send connector C2. Even though the latter address matches the address spaces on both connectors, the address space of C2 is a better match.

Message Size Restrictions

A message size restriction on a connector may also remove that connector from consideration during routing path selection if the message being routed is larger than the size restriction configured on that Send connector.

Cost
Connector cost is used to set selection priority when more than one connector is configured for the same address space. During routing, when the connector selection is made, the lowest cost routing path to the destination is selected. By adjusting connector costs, you can control the preferred routing path for mail flow in your organization and to the Internet. When you create a connector, the default cost is set to 1. Return to top

Selecting the Routing Path to an External Recipient

When a message is sent to an external recipient, Exchange 2010 will always select a single connector through which to send the message. The selected connector must meet the message size constraints. After Exchange 2010 has eliminated all connectors whose message size restrictions are less than the size of the message being routed, routing applies the following criteria to determine which connector it will select:

1. From the list of all the connectors configured in the Exchange organization, Exchange narrows the list to connectors that satisfy all the following criteria: In the scope for the local server Enabled With an address space that matches the recipient's e-mail domain 2. From the resulting list, Exchange selects the connector with the most specific address space match. If more than one connector meets the address space match criteria, Exchange 2010 routing evaluates the following criteria to select a connector:

1. Connector cost The cost of the connector is the sum of the cost assigned to all the IP site links between the source Active Directory site and the Active Directory site that contains the source servers for the connector, and the cost assigned to the connector. The connector with the lowest aggregate cost is selected. If more than one connector has the same cost, the selection process continues to the next step. 2. Proximity The source server that has the closest proximity to the routing server is selected. This means that the local server is chosen over another Hub

Transport server in the same Active Directory site, and a server in the local Active Directory site is chosen over a source server in a remote Active Directory site. If more than one connector matches the criteria, the selection process continues to the next step. 3. Alphanumerically lower connector name If more than one routing path has the same cost and proximity, the connector with the name that has the lowest alphanumeric value is selected.

Routing Path Selection When Coexisting with Exchange 2003

In a coexistence scenario, the selection varies slightly depending on whether the source server for the selected connector is an Exchange 2010 or Exchange 2003 server. If more than one connector meets the address space match criteria, and they are all are hosted on servers running Exchange 2003, the following selection method is used:

1. Connector cost The cost of the connector is the sum of the cost assigned to all the routing group connectors between the routing server and the routing group that contains the source servers for the connector and the cost assigned to the connector. 2. Alphanumerically lower connector name If more than one routing path has the same cost and proximity, the connector with the name that has the lowest alphanumeric value is selected. If more than one connector meets the address space match criteria, and they are spread across Exchange 2010 and Exchange 2003, Exchange 2010 will always prefer Exchange 2010 connectors. When a connector is selected, if there are legacy servers listed as source servers as well as Exchange 2010 servers, messages are routed to the Exchange 2010 servers. When all things are equal, Exchange 2010 will always route the messages to other Exchange 2010 servers. After a connector is selected by using the previous criteria, there may be more than one routing path to reach the Active Directory site where the source server for the selected connector is located. In this case, the lowest cost routing path to the connector is calculated by using the logic used for intra-organizational routing. For more information, see Internal Message Routing.

Handling Messages That Can't Be Routed

If no connector satisfies all criteria required to select a connector according to the logic described earlier, one of the following actions occurs:

If there is no matching connector for an SMTP address space, the recipient is marked as unreachable and the message is routed to the Unreachable queue. If the message size exceeds the connector size restriction for all connectors, a non-delivery report (NDR) is returned to the sender. If there is no matching connector for a non-SMTP address space, an NDR is returned to the sender. Return to top

Routing Examples
The following examples illustrate how messages are routed to external recipients.

Example 1: Selecting a Connector Based on Address Space Match

In this topology, a message is being routed from Active Directory Site A to the external recipient, john@subdomain.contoso.com. The following figure shows that two connectors can route messages to this address space.

The following table shows the configuration of two Send connectors in an Exchange 2010 topology.

Examples of Send connector configurations

Send connector name C1 C2 Address space *.contoso.com subdomain.contoso.com Connector cost 1 10 Source servers Hub Transport servers in Active Directory Site A Hub Transport servers in Active Directory Site B Message size restrictions None None

In this scenario, the message is routed by using C2 because the most specific address space match is chosen. C1 has a lower routing cost, and the source servers are located in the same site as the Hub Transport server processing the message. However, the address space match takes priority over the other factors.

Example 2: Selecting a Connector Based on Proximity

In this scenario, a message is being routed by a Hub Transport server located in Active Directory Site A to the external recipient, john@subdomain.contoso.com, as shown in the following figure.

The following assumptions apply:

The routing server isn't listed as a source server for any Send connector. The IP site link between Site A and Site B is assigned a cost of 5. Two Send connectors can route messages to the address space. The following table shows the connector configuration.

Alternative Send connector configuration

Send connector name C1 C2 Address space subdomain.contoso.com subdomain.contoso.com Address space cost 15 10 Source servers Hub Transport servers in Active Directory Site A Hub Transport servers in Active Directory Site B Message size restrictions None None

Because both connectors have the same address space match, the connector cost is evaluated next. The cost assigned to connector C2 is added to the cost of the IP site link between Active Directory Site A and Site B, for a combined cost of 15. The source servers for connector C1 are located in the local Active Directory site. Therefore, the IP site link cost to reach the connector is 0, for a total cost of 15. In this scenario, both connectors match the address space equally and have an equal cost. Routing selects connector C1 because it has a closer proximity.

Example 3: Selecting a Connector Based on Exchange Version

In the next example, a message is being relayed from Active Directory Site A to the external recipient, john@contoso.com, as shown in the following figure.

The following assumptions apply:

There are two Send connectors that match the destination address space equally. The source servers for the routing group connector between Exchange 2003 and Exchange 2010 are located in Site A. The routing group connector has a routing cost of 5. The IP site link between Site A and Site B is assigned a cost of 5. The source server for one of the Send connectors is an Exchange 2003 server located in routing group 1. The following table shows the connector configuration.

Connectors configured on different versions of Exchange

Connector name C1 C2 Address space *.contoso.com *.contoso.com Address space cost 10 1 Source servers Hub Transport servers in Active Directory Site B Exchange 2003 bridgehead servers in routing group 1 Message size restrictions None None

In this scenario, the aggregate cost of using connector C1 is 15, which is the sum of the IP site link cost and the Send connector cost. The aggregate cost of using connector C2 is 6, which is the sum of the routing group connector cost and the Send connector cost. However, even though C1 has a lower routing cost, Exchange will still route the message to the Exchange 2010 connector. Return to top

2010 Microsoft Corporation. All rights reserved.

 2013 Microsoft. All rights reserved.

Message Rerouting and the Unreachable Queue

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-12-07 In Microsoft Exchange Server 2010, there are message routing scenarios where a message that isn't delivered is put in the Unreachable queue or rerouted. The decision to put a message in the Unreachable queue is made during the routing phase of categorization. If a routing path can't be calculated for a message during the routing phase, the message is sent to the Unreachable queue. The decision to reroute a message occurs during the message delivery phase in the SMTP Send connector process. If there are configuration changes that require a message in the queue to be resubmitted, the message is resubmitted for categorization in the message delivery phase and rerouted with the new configuration information. Depending on the type of configuration change, some or all resubmitted messages may be sent to the Unreachable queue or to a different delivery queue. For more information about how the least-cost routing path is computed, see Understanding Message Routing. For more information about how the categorizer works, see Understanding Transport Pipeline. Looking for management tasks related to message routing? See Managing Message Routing.

Message Rerouting
There are two types of message delivery in Exchange:

Local delivery refers to delivery of messages sent to a recipient with a mailbox in the same Active Directory site as the Hub Transport server on which categorization occurred. Remote delivery refers to delivery of messages to recipients in other Active Directory sites of the Exchange organization and to external recipients. Remote delivery queues are the main focus of message rerouting. Remote delivery can be affected by configuration changes in various ways. The routing component of the categorizer tries to detect whether messages in a queue must be rerouted during enhanced Domain Name System (DNS) resolution. During enhanced DNS resolution, routing tries to detect if a queue has to be rerouted. In this phase, the NextHopSolutionKey attribute is resolved to a list of targets. This enables routing to automatically detect any configuration changes that invalidate or modify the NextHopSolutionKey attribute. If routing detects that configuration changes require rerouting of messages in a queue, the messages in the affected queue are resubmitted to the categorizer and the least cost path is recalculated, taking the new configuration changes into account. The store driver, which delivers inbound messages to the Exchange databases, may also reroute messages. It resubmits a message for rerouting if either of the following conditions is true:

The message is in a MAPI delivery queue, and the next hop has been selected, but the message hasn't been delivered. The destination mailbox is moved to another Mailbox server. If a Mailbox server is unavailable when the store driver tries to deliver the messages to that Mailbox server, the store driver puts the message queue in a retry state. If continued attempts to contact the Mailbox server are unsuccessful, when the retry interval expires, all messages in the queue are resubmitted to the categorizer. If a message is located in a non-SMTP gateway delivery queue (a queue being routed to a Delivery Agent connector or a Foreign connector), the foreign gateway connection handler determines whether the configuration change requires rerouting. The foreign gateway connection handler is a component of the Microsoft Exchange Transport service that manages delivery of messages to Delivery Agent connector queues and Foreign connector Drop directories. For example, deleting or disabling a Foreign connector requires rerouting messages to another connector. The following list summarizes the types of configuration changes that affect message routing. Each configuration change is discussed in detail later in this topic:

Invalid next hop The next hop for the message has been deleted or modified, therefore invalidating the previously calculated routing path. The next hop for a message may be an Active Directory site, a connector, or a transport server (either a Hub Transport server or Edge Transport server). Changes to next hop The configuration of the next hop has changed in a way that affects connectivity. For example, changes to the list of Hub Transport servers in the remote Active Directory site cause the next hop connection to be modified. Less preferred routing paths When configuration changes occur along a previously computed routing path, messages already routed are delivered if the routing path is reachable. But new messages are rerouted with the updated configuration changes. Unavailable next hop Network connectivity or target server availability cause the next hop to be unavailable for connectivity. However, the next hop doesn't change. An example is when the Hub Transport servers in an Active Directory site are offline. Additional scenarios where rerouting occurs In some cases, configuration changes may be caused when DNS MX resource record resolution fails for a DNS connector or a smart host connector. Configuration changes that cause message rerouting or delay When specific configuration changes are detected during the message delivery phase, routing actions occur, and messages are rerouted or delivery is delayed.

Invalid Next Hop

Configuration changes can invalidate a previously calculated next hop. In these circumstances, the routing component of the categorizer can detect the configuration change and reroute to compensate for that change.

Delivery to an SMTP Connector on the Local Computer

When a message is being delivered to an SMTP connector on the local computer, the server that received the message for relay to its destination is also the source server for the Send connector through which the message is routed. This kind of delivery occurs when either of the following conditions is true:

The message was received on a linked Receive connector. The recipient has an external address, and a source server for the selected connector is the local computer.

If the Send connector selected by the routing component of the categorizer is deleted or disabled, the configuration change is detected during the message delivery phase. This causes all messages in the queue to be categorized again. If the configuration of the Send connector is changed to remove the local server as a source server of the connector, the configuration change is detected during the message delivery phase, and all messages in the queue are categorized again. A change of the address resolution method of the Send connector causes the queue to be rerouted. A Send connector can be configured to use DNS to resolve MX records and route messages automatically or it can be configured to route all messages through one or more smart hosts. If you change the address resolution of a Send connector, the messages routed through that Send connector are rerouted.

SMTP Relay in an Active Directory Site

SMTP message relay in an Active Directory site occurs in the following scenarios:

The recipient has an external address, and at least one of the source servers for the Send connector is an Exchange 2010 Hub Transport server located in the local Active Directory site. The recipient has an external address, and at least one of the source servers for the Send connector is an Exchange 2010 Edge Transport server subscribed to the local Active Directory site. The recipient's mailbox is located on a server that runs Exchange Server 2007 in the local Active Directory site. The recipient's mailbox is located on a server that runs Exchange Server 2003, and at least one of the source servers for the selected routing group connector is an Exchange 2010 Hub Transport server in the local Active Directory site. The recipient is a distribution group, and the expansion server for the group is an Exchange 2010 Hub Transport server in the local Active Directory site. In the first four scenarios, if the Send connector is deleted or disabled, the configuration change is detected during the message delivery phase, and the queue is resubmitted. In the last scenario, the messages are queued for delivery to an expansion server and the NextHopSolutionKey attribute contains the fully qualified domain name (FQDN) of the expansion server for the distribution group. If the Hub Transport server role is uninstalled from the specified expansion server, that configuration change is detected during the message delivery phase, and the queue is resubmitted.

SMTP Relay to a Remote Active Directory Site

When a message is being delivered to a remote Active Directory site, the next hop is a different Active Directory site than the Hub Transport server processing the message. This kind of delivery occurs in the following scenarios:

The recipient is a resolved user, mailbox database, or public folder, and the destination computer is an Exchange 2010 server in a remote Active Directory site. The recipient is an external address, and the source servers of the Send connector selected for that address are Exchange 2010 servers in a remote Active Directory site. The recipient is an external address, and the source servers of the Foreign connector selected by the routing component of the categorizer are Exchange 2010 servers in a remote Active Directory site. The recipient is a distribution group, and the expansion server is an Exchange 2010 Hub Transport server in a remote Active Directory site. The recipient's mailbox is located on an Exchange 2003 server, and the closest Hub Transport server listed as a source server for the selected routing group connector is located in a remote Active Directory site. In these scenarios, if the remote Active Directory site is deleted, the configuration change is detected during the message delivery phase, and the queue is resubmitted.

SMTP Relay to an Exchange 2003 Server

When a message is being delivered to an Exchange 2003 server, the Exchange 2010 Hub Transport server relays the message through a routing group connector to an Exchange 2003 server. This delivery type occurs in the following scenarios:

The recipient is a resolved user, mailbox database, or public folder located on an Exchange 2003 server. The recipient is an external address, and the source servers for the SMTP connector selected for that address are Exchange 2003 servers. The recipient is an external address, and the source servers for the selected Foreign connector for that address are Exchange 2003 servers. The recipient is a distribution group, and the designated expansion server is an Exchange 2003 server. In these scenarios, if the routing group connector is deleted, the configuration change is detected during the message delivery phase, and the queue is resubmitted.

Changes to Next Hop

In some scenarios, the next hop isn't invalidated. However, it's modified in a way that affects the connection to a next hop target. Such configuration changes are automatically detected during the message delivery phase, and messages are delivered to the new targets. The following types of changes cause an update of the list of next hop targets:

Changes to the target server list of a routing group connector. Changes to the list of Hub Transport servers in the remote Active Directory site. Changes to the list of Hub Transport servers or Edge Transport servers in the local Active Directory site. The introduction of hub sites along a previously calculated routing path. When this change is detected during the message delivery phase, the IP address list returned to the resolve request is adjusted so that the message is sent to the hub site.

Less Preferred Routing Paths

If a configuration change causes the previously calculated routing path to become less preferred or removes the routing path from consideration, the routing path is still reachable and the messages can still be delivered along the previously calculated routing path. The following configuration changes are in this category:

Message size restrictions are added along the routing path. This causes messages that exceed the size limit to be routed along a different routing path. A routing path with better cost or proximity is created. The address space of the connector changes. Other connector-related changes occur, such as the enabling of a connector or modification of the scope for a connector. For example, if a connector whose scope is changed from global to scoped is in the local Active Directory site, the change has no effect. If the connector is in a remote Active Directory site, the change isn't detected during the message delivery phase because the messages are queued to the remote Active Directory site instead of to the connector. As the routing path tries to SMTP-relay to a Mailbox server in the remote Active Directory site, the Mailbox server moves from a remote Active Directory site to a local Active Directory site. The routing path is trying to reach the expansion server for a distribution group when it's no longer an expansion server. In these scenarios, existing messages are delivered along the already calculated routing path. Because the routing path exists and is reachable, messages already routed are unaffected by these configuration changes. However, newly submitted messages are routed by using the updated configuration.

Unavailable Next Hop

In this scenario, a configuration change or network connectivity change doesn't invalidate the next hop to which messages are routed but a configuration change or network connectivity change makes the next hop unavailable. This means that an SMTP connection can't be established to the next hop target for some reason. Possible reasons are as follows:

An attempt is made to establish an SMTP connection with a currently offline Hub Transport server in the local site. A remote Active Directory site has unavailable or offline Hub Transport servers. A remote routing group has unavailable or offline Exchange 2003 bridgehead servers. Remote domains are unavailable because of network connectivity issues. Message delivery failures caused by network connectivity problems aren't detected by the routing component of the categorizer. When an SMTP connection can't be established to the next hop target, the SMTP Send connector retries the queue. The MaxIdleTimeBeforeResubmit parameter, which is located in the EdgeTransport.exe.config file, has a default value of 12 hours. After the configurable retry interval (MaxIdleTimeBeforeResubmit) has expired without successfully establishing a connection, all messages from the delivery queue are resubmitted to the Submission queue. If the connectivity problem still exists, this process is repeated. If the connectivity problem is resolved, messages are delivered as soon as message retry is successful. Or, a configuration change that modifies the next hop destination may resolve the problem. For example, if the problem is caused by all the Hub Transport servers in a destination site being offline, and you move mailboxes to a server in a different site, the next hop would change to the new site. Note: The automatic resubmission from the message delivery queue to the Submission queue only happens for queues that aren't connector queues. Connector queues remain in retry mode until the problem is fixed, or the messages expire and a non-delivery report (NDR) is sent.

Additional Scenarios Where Rerouting Occurs

In addition to the scenarios described earlier in this section, the following scenarios cause messages to be rerouted during the message delivery phase:

DNS MX resolution fails for a DNS connector. If the DNS MX resolution fails because the authoritative host for the MX record wasn't found, an NDR for the messages in the queue is sent immediately. If other types of failures exist, the queue is put into retry mode until a connection is established or the messages expire. DNS MX resolution fails for a smart host connector. The queue is put into retry mode until the messages expire.

Configuration Changes That Cause Message Rerouting or Delay

The following table summarizes the routing actions taken when specific configuration changes are detected during the message delivery phase, and messages are rerouted or delivery is delayed.

Configuration changes that cause message rerouting and delay

Routing scenario Message is routed to a DNS connector configured on the local server. Configuration change The connector is deleted. The connector is changed to a smart host connector. The connector is modified to remove the local server from the source server list. A fatal DNS MX resolution failure occurs. A DNS MX resolution failure that isn't fatal occurs. Routing action The queue is resubmitted. The queue is resubmitted. The queue is resubmitted. Configuration change and routing action

An NDR is sent. The queue is retried until messages

expire. The connector is disabled. The queue is resubmitted.

Message is routed to a smart host connector configured on the local server. Configuration change The connector is deleted. The connector is modified to remove the local server from the source server list. The connector is changed to a DNS connector. The smart host list for the connector is modified. Any DNS MX resolution failure occurs. The connector is disabled. The SMTP server is offline or the destination isn't running an SMTP server. Routing action The queue is resubmitted. The queue is resubmitted.

The queue is resubmitted.

The updated smart hosts list is automatically detected and used during the message delivery phase. The queue is retried until messages expire. The queue is resubmitted. The queue is retried until messages expire.

Message is routed to a connector with a source Hub Transport server or Edge Transport server in the local Active Directory site.

Configuration change The connector is deleted. The source server list for the connector is modified to remove or add Hub Transport or Edge Transport servers in the local Active Directory site. The source server list for the connector is modified to remove all Hub Transport or Edge Transport servers in the local Active Directory site.

Routing action The queue is resubmitted. Changes to source servers in the local site are automatically detected and used during the message delivery phase. The queue is resubmitted.

Message is routed to an expansion server for a distribution group in the local Active Directory site. Configuration change The server is no longer configured for the Hub Transport server role. Routing action The queue is resubmitted.

Message is routed to a transport server in the local Active Directory site. Configuration change The server is offline or the Microsoft Exchange Transport service isn't running. Routing action The queue is resubmitted after an interval.

Message is routed to a remote Active Directory site. Configuration change The remote Active Directory site is deleted. The link to the remote Active Directory site is deleted. Therefore, the site is unreachable from the local site. The list of Hub Transport servers in the remote Active Directory site changes. All Hub Transport servers in the remote Active Directory site are removed. Hub sites are introduced along the routing path of the destination Active Directory site. Routing action The queue is resubmitted. The queue is resubmitted.

Changes are automatically detected and used during the message delivery phase. The queue is resubmitted.

Changes are automatically detected and used during the message delivery phase so that the messages are relayed to the hub site. The queue is resubmitted after an interval.

All Hub Transport servers in the remote

Active Directory site are offline. The remote site is the delayed fan-out point, and all Hub Transport servers in the site are offline. The queue is resubmitted after an interval.

The message is routed to an Exchange 2003 server in a remote routing group. Configuration change The connector is deleted. The source Hub Transport server list for the connector changes to remove the local server from the list. The target bridgehead server list for the connector is changed by removing or adding bridgehead servers in the remote routing group. All Exchange 2003 bridgehead servers in the remote routing groups are offline. Routing action The queue is resubmitted. The queue is resubmitted.

Changes are automatically detected and used during the message delivery phase. The queue is retried until messages expire.

The message is routed to a destination, and there are configuration changes, but the destination is still reachable.

Configuration change The routing path becomes less preferred because a new routing path appears with a reduced cost or closer proximity, or both.

Routing action Changes are automatically detected and used during the message delivery phase. Changes are automatically detected and used during the message delivery phase. Changes are automatically detected and used during the message delivery phase. Changes are automatically detected and used during the message delivery phase. Changes are automatically detected and used during the message delivery phase. Changes are automatically detected and used during the message delivery phase. Changes are automatically detected and used during the message delivery phase.

The routing path is removed for a message because maximum message size restrictions are added along the path.

A previously disabled routing path comes into consideration with a reduced cost because the connector is enabled, put back in scope, or has no message size restrictions. The connector address space changes.

The connector is changed to add local Hub Transport or Edge Transport servers to the source server list.

The message is relayed to a Mailbox server in the remote Active Directory site, while the Mailbox server housing the destination mailbox database is moved to a different site. The message is relayed to a distribution group expansion server when it's no longer an expansion server. (The distribution group's HomeMTA attribute is modified.)

The message is routed by using MAPI delivery to a Mailbox server. Configuration change The mailbox moves to a different Mailbox server. The Mailbox server is offline. Routing action The store driver detects the change and resubmits the messages. The queue is retried and resubmitted after an interval.

The message is routed by using a non-SMTP gateway to a non-SMTP connector configured on the local server.

Configuration change A Foreign connector is deleted. A Foreign connector is modified to remove the local server from the source server list. The connector is disabled. The Drop directory isn't found.

Routing action The queue is resubmitted. The queue is resubmitted.

The queue is resubmitted. The queue is retried until

messages expire.

Unreachable Queue
The Unreachable queue contains messages that can't be routed to their destinations. Typically, an unreachable destination is caused by misspelled e-mail addresses, or configuration changes that have modified the routing path for delivery. Regardless of destination, all messages that have unreachable recipients reside in this queue. The decision to put a message in the Unreachable queue is made during the routing phase of categorization. If a routing path can't be calculated for a message during the routing phase, the message is sent to the Unreachable queue. Messages in the Unreachable queue are rerouted after configuration changes are processed. There is only one Unreachable queue for each Exchange 2010 transport server. During categorization, messages are put in the Unreachable queue when the following conditions are true:

The recipient is a valid Active Directory recipient object. However, a routing path can't be calculated for that recipient. The recipient is an external SMTP address and a matching connector can't be found for the address space. A matching connector may also be ignored by the routing component of the categorizer because it's disabled or configured incorrectly. The recipient is a distribution group. The expansion server for the distribution group is invalid or doesn't have the Hub Transport server role installed. The recipient is an SMTP address recipient of a message received on a Receive connector linked to a Send connector that's ignored by the routing component of the categorizer because it's disabled or configured incorrectly in some way. In the following scenarios, messages aren't put in the Unreachable queue, and NDRs are sent instead:

The routing path can't be calculated for a recipient because constraints, such as message size restrictions, prevent delivery of the message using the single, deterministic route calculated by the categorizer. The recipient is a non-SMTP address and a matching connector can't be found. Or the matching connector is disabled or configured incorrectly. The recipient is a non-SMTP address recipient received on a Receive connector linked to a Send connector that's ignored by the routing component of the categorizer because the Send connector is disabled or configured incorrectly. Messages in the Unreachable queue are resubmitted to the categorizer when the routing tables are rebuilt because of configuration changes. The old routing tables and new routing tables are compared. The Unreachable queue is resubmitted only if the old routing tables and new routing tables aren't the same.

Scenarios Where Messages Are Put in the Unreachable Queue

This section describes some scenarios where messages are put in the Unreachable queue.

Routing group connector between an Exchange 2010 organization and Exchange 2003 organization doesn't exist A routing group connector between the Exchange 2010 routing group and Exchange 2003 routing groups hasn't been configured, or the last routing group connector between the Exchange 2010 routing group and Exchange 2003 routing groups has been removed. No routing group connector exists to provide a routing path to the Exchange 2003 recipients. To resolve this problem, first verify that the routing group connector is missing. If that's the case, you can create a routing group connector. For more information, see Create Additional Routing Group Connectors from Exchange 2010 to Exchange 2003. If a routing group connector does exist, the message is in the Unreachable queue for some other reason. Check the configuration of the routing group connector.

Destination Active Directory site doesn't have Hub Transport servers The destination Active Directory site has no Hub Transport servers. In this scenario, messages to recipients in that site are sent to the Unreachable queue. To resolve this problem, deploy a Hub Transport server in the Active Directory site. For more information, see Overview of the Hub Transport Server Role.

Active Directory site link doesn't exist between two Active Directory sites An Active Directory site link has been removed and as a result, a disconnected Active Directory site contains Exchange 2010 servers. To resolve this problem, create an Active Directory site link by using Active Directory Sites and Services.

Other issues When a message is put in the Unreachable queue, the last error message specifies why the message was placed in the Unreachable queue. If more than one recipient of the same message is routed to the Unreachable queue, but for different reasons, the last error available on each recipient specifies the reason for each. When inconsistencies are found during routing table computation, events are logged in the Application log of Windows Event Viewer. The last error message and these events can help you determine the configuration error and make corrections so that messages in the Unreachable queue can be routed successfully. You can also manually force the messages in queues to be resubmitted. For more information, see Resubmit Messages in Queues.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Internal Message Routing

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-12-07 Internal message delivery involves a routing process that relays e-mail in the following ways:

From a server running Microsoft Exchange Server 2010 that has the Hub Transport server role installed to an Exchange Server 2007 or Exchange 2010 Hub Transport server in a different Active Directory site From an Exchange 2010 Hub Transport server to an Exchange 2010 Mailbox server located in the same Active Directory site From an Exchange 2010 Hub Transport server to a Hub Transport server running Exchange 2007 for delivery to a recipient mailbox located on an Exchange 2007 server From an Exchange 2010 Hub Transport server to a server running Exchange Server 2003 for delivery to a recipient mailbox located on an Exchange 2003 server From an Exchange 2010 Hub Transport server to an Exchange 2010 Mailbox server for delivery to a mail-enabled public folder For more information about how Exchange makes routing decisions, see Understanding Message Routing. Looking for management tasks related to message routing? See Managing Message Routing. Contents Routing Messages for Delivery to Exchange 2010 Servers Routing Messages for Delivery to Exchange 2007 Servers Routing Messages for Delivery to Exchange 2003 Servers Routing to Public Folders

Routing Messages for Delivery to Exchange 2010 Servers

In Exchange 2010, after a message is received by the Hub Transport server, the message is added to the Submission queue. Messages move from the Submission queue through the categorizer. When the message is categorized, a recipient's e-mail address is resolved to an object in Active Directory. This query determines the mailbox associated with that e-mail address and which Mailbox server is hosting that mailbox. After information about the recipient is resolved, the next step is resolving the Mailbox server to an Active Directory site. This Active Directory site information is stamped on the message as the NextHopSolutionKey attribute. The enhanced DNS component of the Microsoft Exchange Transport service accesses the topology information to determine which Hub Transport servers are located in the same site as the destination Mailbox server. A list of Hub Transport servers in the Active Directory site is then referenced to determine where to route the message. If the destination Mailbox server is located in the same site as the querying Hub Transport server, that Hub Transport server queues the message for local delivery. If the destination Mailbox server is located in a different site, the local Hub Transport server queues the message for remote delivery to that Active Directory site. A message queued for local delivery is submitted to the destination mailbox store by the store driver. The message is transferred from the Hub Transport server to the Mailbox server by using an Exchange remote procedure call (RPC). A message queued for delivery to a remote Active Directory site is transferred by using SMTP. Before the message is relayed, the routing component of the categorizer selects the least cost routing path. The method for determining the least-cost routing path is explained in detail in "Determining the Least-Cost Routing Path" in Understanding Message Routing. Return to top

Routing Messages for Delivery to Exchange 2007 Servers

Due to the changes made to the Exchange Server Object (XSO) model in Exchange 2010, Exchange 2010 Hub Transport servers can't pick up messages from and deliver messages to Exchange 2007 Mailbox servers. Similarly, Exchange 2007 Hub Transport servers can't communicate with Exchange 2010 Mailbox servers. As a result, to have both Exchange 2010 and Exchange 2007 in the same Active Directory site, you must maintain both versions of Hub Transport servers in that site. When a Hub Transport server queries Active Directory to determine the Mailbox server hosting the destination mailbox, it also retrieves the version of the Mailbox server. If the Mailbox server is an Exchange 2007 server that's in the same site as the Hub Transport server, the Hub Transport server will relay the message to an Exchange 2007 Hub Transport server in the same Active Directory site. The process of using the version information to make routing decisions is called versioned routing and is explained in detail in Upgrade from Exchange 2007 Transport. If the Mailbox server is in a different Active Directory site, the message is queued for delivery to that remote site and is transferred by using SMTP. Return to top

Routing Messages for Delivery to Exchange 2003 Servers

The routing topology and components of Exchange 2010 differ significantly from those of Exchange 2003 but generally correlate in the following ways:

The Active Directory site in Exchange 2010 correlates to routing groups in Exchange 2003. IP site links in Exchange 2010 correlate to the concept of routing group connectors in Exchange 2003. The functionality of the Hub Transport server role in Exchange 2010 correlates to the functionality of a dedicated bridgehead server in Exchange 2003. However, each Exchange version differs in the method used to determine routing paths. For more information about the routing differences, see Upgrade from Exchange 2003 Transport. A message relayed from a Hub Transport server to an Exchange 2003 server for delivery to a recipient mailbox located on an Exchange 2003 server must be relayed across a routing group connector. All Exchange 2010 servers are associated with a single routing group named Exchange Routing Group (DWBGZMFD01QNBJR) for the purposes of routing to earlier versions of Exchange when Exchange 2010 coexists in the same organization with Exchange 2003. Placement of Exchange 2010 and earlier versions of Exchange in the same routing group isn't supported. Therefore, at least one routing group connector will always separate Exchange 2010 servers from Exchange 2003 servers. When an Exchange 2010 Hub Transport server determines the least-cost routing path to an Exchange 2003 server, the routing component of the Microsoft Exchange Transport service uses the following algorithm to select the least-cost routing path to a computer running Exchange 2003:

1. Examine all possible routing paths across routing group connectors and select the routing path that has the least total cost. 2. If more than one routing path has the same cost, examine all possible routing paths across IP site links to reach the first routing group connector and select the routing path that has the lowest total IP site link cost. 3. If more than one routing path has the same routing group cost and has the same IP site link cost, select the routing path that includes the least number of hops. 4. If more than one routing path has the same routing group cost, the same IP site link cost, and the same number of hops, select the routing path where the name of the last Active Directory site before the destination site has the lowest alphanumeric value. The following figure shows an example of a routing topology where Exchange 2010 and Exchange 2003 coexist.

In this example, a message is being routed from a Hub Transport server in Site A to an Exchange 2003 server located in routing group 2. Two possible routing paths exist to reach routing group 2:

Option 1: From routing group connector A3 at a cost of 10, to routing group connector 2-3 at a cost of 20. This routing path has a total cost of 30. Option 2: From routing group connector C1 at a cost of 10, to routing group connector 1-2 at a cost of 10. This routing path has a total cost of 20. In this example, Option 2 has a lower total routing group connector cost, and the message is routed from the Hub Transport server in Site A, to a Hub Transport server in Site C where it's queued for delivery by using routing group connector C1. The previous example shows how the routing decisions may not result in optimal routing due to the assigned costs on the routing group connectors. To maintain optimal routing, you may need to modify the routing group connector costs you have in your organization. The following figure shows the same topology, but with the cost of routing group connector 2-3 changed to 10.

Again, two possible routing paths are available to reach routing group 2:

Option 1: From routing group connector A3 at a cost of 10, to routing group connector 2-3 at a cost of 10. This routing path has a total cost of 20. Option 2: From routing group connector C1 at a cost of 10, to routing group connector 1-2 at a cost of 10. This routing path has a total cost of 20. In this scenario, both options have the same total routing group connector cost. Routing next evaluates the cost of the IP site links that must be crossed to reach the first routing group connector. From Site A, the IP site link cost to reach routing group connector A3 is zero, and the cost to reach routing group connector C1 is 20. Therefore, the routing path described in Option 1 is selected. Return to top

Routing to Public Folders

Public folders can be mail-enabled in Exchange. Users can send messages to mail-enabled public folders just like any other recipient. When a Hub Transport server receives a message sent to a mail-enabled public folder, the following routing process applies:

1. The categorizer must determine which public folder hierarchy in which the public folder resides. 2. The categorizer looks up the homeMDB attribute for the public folder. The homeMDB attribute identifies the public folder hierarchy where the destination public folder is located. 3. Based on the routing table calculations performed by the Microsoft Exchange Transport service, and described in "Selecting the Destination Public Folder Database" later in this topic, the preferred public folder database is used to determine which public folder hierarchy contains a replica of the destination public folder. If the preferred public folder database is located in the same Active Directory site as the routing Hub Transport server, message processing proceeds as described in step 4 in this section. If the preferred public folder database is located in a remote Active Directory site, the message is relayed to that site by using the least cost routing path. The message categorization process described in step 1 and step 2 earlier in this section are repeated by the Hub Transport server that receives the message in the remote site. If the preferred public folder database is located on an Exchange 2007 or Exchange 2003 server, the message is relayed to the Exchange 2007 Hub Transport server or the Exchange 2003 bridgehead server, and message delivery is determined by the earlier version of Exchange. 4. The Hub Transport server establishes a connection to the store driver on the Mailbox server that contains the preferred public folder database. The public folder database is queried to determine whether content for the public folder is available. The identity of the destination folder is referenced by the legacyExchangeDN attribute, and content availability is determined by the value of the IsContentAvailable attribute. The store driver either accepts the message for delivery, or if the folder contents aren't available locally, the store driver responds with a list of alternative servers that contain a replica of that public folder. The behavior of returning an alternative list of servers is known as store override. The alternative list of servers that contain the public folder replica is listed in the same order provided in client folder referrals, and the top entry is chosen by transport. This referral is provided to routing as the destination to which the message should be routed. For more information about client folder referrals, see Configure Public Folder Referrals. 5. If store override occurs, the Hub Transport server uses the routing table to determine the least cost routing path to the server that contains the preferred public folder replica and routes the message to that destination. 6. The message is delivered to the public folder store.

Selecting the Destination Public Folder Database

Public folders are stored in databases created on Mailbox servers. For efficiency and fault tolerance, you can replicate the content in your public folders to multiple Mailbox servers. Public folder content exists only in Exchange databases configured to have a replica of a specific folder, whereas the hierarchy is replicated to all public folder databases. Content and hierarchy information are replicated separately. Public folder hierarchies are retrieved when routing tables are calculated. The top-level hierarchy object has a list of all the public folder databases to which that hierarchy is replicated. This list of public folder databases is stored as the msExchOwningPFTreeBL attribute in Active Directory. The msExchOwningPFTreeBL attribute always lists the most recently added public folder databases at the top of the list. In Exchange 2010, the preferred public folder hierarchy database is selected by using the following criteria:

1. Ranking by the age of the public folder database By default, public folder databases that have an age threshold of less than two days aren't considered unless the age of all public folder databases is less than the threshold or the age is unknown. 2. Proximity Thelocal server is preferred. If the local server doesn't contain a replica of the public folder database, a server in the same Active Directory site is preferred. If the local Active Directory site doesn't contain a replica of the public folder database, a server in a remote Active Directory site or routing group is selected as the preferred destination. 3. Cost If more than one remote Active Directory site or routing group contains a replica of the public folder database, the server in the Active Directory site or routing group that has the least cost routing path from the local Active Directory site is selected as the preferred destination. If more than one server still meets the criteria, the first server in the replica list returned by Active Directory is selected. After the hierarchy is read, Exchange then determines which public folder databases have replicas of the content. To make sure that correct message delivery can occur to the public folder replica, a preferred public folder database is selected by the routing component of the Microsoft Exchange Transport service from the msExchOwningPFTreeBL list. This selection is made by using the following evaluation process:

1. If only a single instance of a public folder database exists, the server that hosts that database is selected. 2. If the list contains any public folder databases located on servers running Exchange 2007 or Exchange Server 2003, these public folder databases are removed from consideration as the preferred public folder database if a replica also exists on an Exchange 2010 Mailbox server. 3. If more than one Exchange 2010 public folder database is available, the following criteria are used to select a preferred public folder database: a. Ranking by the age of the public folder database The older a public folder database is, the more likely it is to have a replica of the target public folder. Therefore, all public folder databases listed in the msExchOwningPFTreeBL list are ranked according to their date of creation by using a configurable number of days as a baseline. The age ranking for each public folder database can be one of the following, listed from best to worst: More than baseline days old Less than baseline days old Unknown The public folder database that has the best age rating is selected as the preferred public folder database. By default, the baseline age for public folder replicas is two days (48 hours). You can modify this value by editing the PFReplicaAgeThreshold key in the EdgeTransport.exe.config file. This file is located in the %ProgramFiles%\Microsoft\Exchange Server\V14\Bin directory on a computer running Exchange 2010. b. Proximity If more than one public folder database has the best age rating, the Mailbox server that has the best proximity rating is selected. The proximity rating for each public folder database can be one of the following, listed from best to worst: Local server If the local server contains a replica of the public folder database, it's selected as the preferred destination for routing to public folders contained in that hierarchy. Server located in the local Active Directory site If more than one server on the list is located in the local Active Directory site, the first server on the list is selected as the preferred destination for routing to public folders contained in that hierarchy.

 Server located in a remote Active Directory site If the list contains servers from multiple remote Active Directory sites, the server in the Active Directory site that has the least cost routing path from the local Active Directory site is selected as the preferred destination for routing to public folders contained in that hierarchy. If there is more than one server in that site that has a replica of the public folder database, the first server on the list is selected. If more than one remote Active Directory site has the same value for the least cost routing path, the first server on the list is selected. 4. If no public folder database replica is located on an Exchange 2010 Mailbox server, a public folder database located on an Exchange 2007 server is selected as the preferred destination. If there are no Exchange 2007 servers, a public folder database located on an Exchange 2003 computer is selected as the preferred destination for routing to public folders contained in that hierarchy. In either case, the destination public folder database is selected by the age ranking of the public folder database. The age ranking is determined by using the same method as for an Exchange 2010 server. If more than one public folder database has the same age ranking, the first server on the list is selected. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Using Exchange 2010 Transport to Relay Application Server SMTP Traffic

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-01-16 In Microsoft Exchange Server 2010, the Receive connector and load-balancing concepts remain the same as in Exchange Server 2007. Heres a quick review of those concepts. In Exchange 2007, Receive connectors are used to accept incoming messages. By default, when an Exchange Server 2007 Hub Transport server receives an e-mail message via SMTP over TCP port 25, it's processed by the Receive connector named Default Receive connector. In addition, Exchange 2007 automatically load-balances all intra-organization message traffic between Edge Transport, Hub Transport, and Mailbox servers using enhanced DNS. However, this functionality doesn't cover the load-balancing of messages received from non-Exchange sources, such as external mail servers, third-party anti-spam or antivirus solutions, any internal mail servers outside your Exchange organization, line-of-business (LOB) applications, and POP-based or IMAP-based e-mail clients. For more information about how you configure load balancing for messages received from non-Exchange sources, see Understanding SMTP Failover and Load Balancing in Transport. If you place a load-balancing solution in front of your Hub Transport servers, you need to create a separate Receive connector for that purpose and make sure that only traffic processed by that specific connector is subject to load balancing. This is achieved by adding an additional IP address to the Hub Transport server and associating this IP address with the new Receive connector.

Changes in Behavior with Exchange 2010

Exchange 2010 introduces the shadow redundancy feature which provides redundancy for messages for the entire time theyre in transit. With shadow redundancy, the deletion of a message from the transport databases is delayed until the transport server verifies that all of the next hops for that message have completed delivery. Because shadow redundancy is an Exchange 2010 feature, shadow redundancy is only supported by Exchange 2010 servers. If an Exchange 2010 transport server receives messages from a previous version of Exchange Server or a non-Exchange source, the source server cant send the expected XSHADOW command. Therefore, shadow redundancy isnt used. Non-Exchange sources include external mail servers, third-party anti-spam or antivirus solutions, any internal mail servers outside your Exchange organization or line-of-business (LOB) applications the source server. However, when an Exchange 2010 transport server receives a message from a non-Exchange 2010 source, Exchange attempts to achieve shadow redundancy by delaying the acknowledgement to the sending server until it verifies that the message has been successfully delivered to all next hops internally. This way, if the Exchange 2010 server fails, the sending server assumes that the message was never delivered to Exchange and attempts delivery again. The delayed acknowledgement time-out is controlled by the MaxAcknowledgementDelay attribute of each Receive connector. The default value is 30 seconds. For more information about shadow redundancy, see Understanding Shadow Redundancy. Customers who have upgraded from Exchange 2007 to Exchange 2010 and use dedicated Receive connectors for the purpose of relaying messages from sources such as line-of-business (LOB) applications may see a significant decrease in SMTP throughput. This decrease in throughput is because of the default delayed acknowledgement time-out of 30 seconds configured for a Receive connector. To increase the SMTP throughput for the relay Receive connector, we recommend you either lower the time-out value for the delayed acknowledgement attribute or disable it completely. Whether you should lower or disable the time-out value depends on the amount of messages that go through the relay Receive connector. A good approach is to first lower the value and then verify whether SMTP throughput still suffers and, if it does, then disable the feature completely. Important: Although disabling delayed acknowledgements for a Receive connector increases SMTP throughput, it also means that you no longer benefit from the features provided by shadow redundancy. For this reason, we recommend the use of storage hardware redundancy for transport servers for which delayed acknowledgements are disabled.

Use the Shell to configure the maximum acknowledgement delay on a Receive connector
You need to be assigned permissions before you can perform this procedure. To see what permissions you need, see the "Receive connectors" entry in the Transport Permissions topic. Note: You can't use the Exchange Management Console to configure the maximum acknowledgement delay on a Receive connector. This example lowers the time-out value for a Receive connector named SMTP Application relay from 30 to 15 seconds.

Set-ReceiveConnector "SMTP Application relay" -MaxAcknowledgementDelay 15

This example disables delayed acknowledgement on the Receive connector.

Set-ReceiveConnector "SMTP Application relay" -MaxAcknowledgementDelay 0

Important: It isnt possible to disable shadow redundancy for a Receive connector. Instead, you must do this on the Exchange organization level. For detailed syntax and parameter information, see Set-TransportConfig.

Message Throttling Policy Considerations

When relaying application server SMTP traffic through an Exchange 2010 transport server, there are Receive connector specific message throttling policy options that may need to be adjusted, so the overall SMTP throughput doesnt suffer. For example, the MessageRateLimit parameter specifies the maximum number of messages that a Receive connector accepts from a single IP address per minute. On Hub Transport servers, this parameter is set to a value of Unlimited, which means SMTP throughput wont be affected. But, for an Edge Transport server, its set to accept 600 messages per minute. Depending on the relay application server SMTP traffic in your specific environment, you may need to raise this limit. This example raises the message rate limit for a Receive connector named SMTP Application relay from 600 to 2000.

Set-ReceiveConnector "SMTP Application relay" -MessageRateLimit 2000

Another Receive connector specific option that can have an impact on overall SMTP throughput from a relay application server is expressed in the value of the MessageRateSource parameter. With this parameter, you specify how the message submission rate is calculated. It can be set to None, IPAddress, User, or All. By default, the parameter is set to IPAddress, which means the message submission rate is calculated for sending hosts. If this parameter has a negative impact on SMTP throughput from your relay application servers, you should consider setting the value to None. This example disables the MessageRateSource parameter for a Receive connector named SMTP Application relay.

Set-ReceiveConnector "SMTP Application relay" -MessageRateSource None

If youre planning to use a dedicated transport server for relay application server SMTP traffic, you should also consider increasing the maximum number of connections that a Receive connector will serve at the same time from a single IP address. This is done using the MaxInboundConnectionPercentagePerSource parameter. The value for this parameter is expressed as the percentage of available remaining connections on a Receive connector. By default, the value is set to 2 percent. This example changes the value of MaxInboundConnectionPercentagePerSource for a Receive connector named SMTP Application relay from 2 to 30 percent.

Set-ReceiveConnector "SMTP Application relay" - MaxInboundConnectionPercentagePerSource 30

For detailed syntax and parameter information for the above Receive connector specific parameters, see Set-ReceiveConnector.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Transport
Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-02-09 The component of Microsoft Exchange that is responsible for transferring messages is known as Transport. The following topics provide detailed information about the Transport features in Exchange Server 2010: Overview of the Edge Transport Server Role Overview of the Hub Transport Server Role Understanding Accepted Domains Understanding Address Rewriting Understanding Anti-Spam and Antivirus Functionality Understanding Approval Framework Understanding Back Pressure Understanding Content Conversion Understanding Delivery Agents Understanding DSNs and NDRs Understanding DNS Query Failure Sensitivity Understanding Domain Security Understanding Edge Subscriptions Understanding Edge Transport Server Cloned Configuration Understanding the EdgeTransport.exe.Config File Understanding Exchange 2010 Support for X.400 Authoritative Domains Understanding Foreign Connectors Understanding Group Metrics Understanding Header Firewall Understanding SMTP Failover and Load Balancing in Transport Understanding Journaling Understanding MailTips Understanding Message Routing Understanding Message Size Limits Understanding Message Throttling Understanding Moderated Transport Understanding the Pickup and Replay Directories Understanding Priority Queuing Understanding Receive Connectors Understanding Recipient Resolution Understanding Remote Domains Understanding Send Connectors Understanding Shadow Redundancy Understanding TLS Certificates Understanding Transport Agents Understanding Transport Database Configuration Options Understanding Transport Logs Understanding Transport Pipeline

Understanding Transport Policy and Compliance Agents Understanding Transport Queues Understanding Transport Rules 2010 Microsoft Corporation. All rights reserved.
2013 Microsoft. All rights reserved.

Overview of the Edge Transport Server Role

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 In Microsoft Exchange Server 2010, the Edge Transport server role is deployed in your organization's perimeter network. Designed to minimize the attack surface, the Edge Transport server handles all Internet-facing mail flow, which provides SMTP relay and smart host services for the Exchange organization. Additional layers of message protection and security are provided by a series of agents that run on the Edge Transport server and act on messages as they're processed by the message transport components. These agents support the features that provide protection against viruses and spam and apply transport rules to control message flow. The computer that has the Edge Transport server role installed doesn't have access to Active Directory. All configuration and recipient information is stored in Active Directory Lightweight Directory Services (AD LDS). To perform recipient lookup tasks, the Edge Transport server requires data that resides in Active Directory. This data is synchronized to the Edge Transport server using EdgeSync. EdgeSync is a collection of processes that are run on a computer that has the Hub Transport server role installed to establish one-way replication of recipient and configuration information from Active Directory to the AD LDS instance on an Edge Transport server. The Microsoft Exchange EdgeSync service copies only the information that's required for the Edge Transport server to perform anti-spam configuration tasks and the information about the connector configuration that's required to enable end-to-end mail flow. The Microsoft Exchange EdgeSync service performs scheduled updates so that the information in AD LDS remains current. You can install more than one Edge Transport server in the perimeter network. Deploying more than one Edge Transport server provides redundancy and failover capabilities for your inbound message flow. You can load-balance SMTP traffic to your organization between Edge Transport servers by defining more than one mail exchange (MX) resource record with the same priority in the Domain Name System (DNS) database for your mail domain. You can achieve consistency in configuration between multiple Edge Transport servers by using cloned configuration scripts. The message-processing scenarios that you can manage on the Edge Transport server role are described in the following sections. Looking for management tasks related to managing transport servers? See Managing Transport Servers.

Internet Mail Flow

Servers that run the Edge Transport server role accept messages that come into the Exchange 2010 organization from the Internet. After the messages are processed by the Edge Transport server, they are routed to Hub Transport servers inside the organization. All messages that are sent to the Internet from the organization are routed to Edge Transport servers after the messages are processed by the Hub Transport server. You can configure the Edge Transport server to use DNS to resolve MX resource records for external SMTP domains, or you can configure the Edge Transport server to forward messages to a smart host for DNS resolution. For more information about mail flow, see Understanding Transport Pipeline.

Anti-Spam and Antivirus Protection

In Exchange 2010, the anti-spam and antivirus features provide services to block viruses and spam, or unsolicited commercial e-mail, at the network perimeter. Most viruses use spam-like tactics to gain access to your organization and to entice users to open an e-mail message. If you can filter out most of your spam, you're also more likely to capture viruses before they enter your organization. Spammers use a variety of techniques to send spam into your organization. Servers that run the Edge Transport server role help prevent users in your organization from receiving spam by providing a collection of agents that work together to provide different layers of spam filtering and protection. Establishing tarpitting intervals on connectors makes e-mail harvesting attempts ineffective. For more information about the anti-spam and antivirus features in Exchange 2010, see Understanding Anti-Spam and Antivirus Functionality.

Edge Transport Rules

Edge Transport rules are used to control the flow of messages that are sent to or received from the Internet. The Edge Transport rules help protect corporate network resources and data by applying an action to messages that meet specified conditions. These rules are configured for each server. Edge Transport rule conditions are based on data, such as specific words or text patterns in the message subject, body, header, or From address, the spam confidence level (SCL), or attachment type. Actions determine how the message is processed when a specified condition is true. Possible actions include quarantine of a message, dropping or rejecting a message, appending additional recipients, or logging an event. Optional exceptions exempt particular messages from having an action applied. For more information about the Edge Transport rules, see Understanding Transport Rules.

Address Rewriting
You use address rewriting to present a consistent appearance to external recipients of messages from your Exchange 2010 organization. You configure the Address Rewriting agent on the Edge Transport server role to enable the modification of the SMTP addresses on inbound and outbound messages. Address rewriting is especially useful when a newly merged organization that has several domains wants to present a consistent appearance of e-mail addresses to external recipients. For more information about address rewriting, see Understanding Address Rewriting.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Overview of the Hub Transport Server Role

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 Deployed inside your Active Directory forest, the Hub Transport server role handles all mail flow inside the organization, applies transport rules, applies journaling policies, and delivers messages to a recipient's mailbox. Messages that are sent to the Internet are relayed by the Hub Transport server to the Edge Transport server role that's deployed in the perimeter network. Messages that are received from the Internet are processed by the Edge Transport server before they're relayed to the Hub Transport server. If you don't have an Edge Transport server, you can configure the Hub Transport server to relay Internet messages directly or utilize a third-party smart host. You can also install and configure the Edge Transport server agents on the Hub Transport server to provide anti-spam and antivirus protection inside the organization, although this isn't recommended. You can install the Hub Transport server role on the same hardware with any other internal server role or on a server that's dedicated to the Hub Transport server role. You must deploy a Hub Transport server role in each Active Directory site that contains a Mailbox server role. Deploying more than one Hub Transport server per site provides redundancy. When you install more than one Hub Transport server in an Active Directory site, the connections are distributed. The message-processing scenarios that you can manage on the Hub Transport server role are described in the following sections. Looking for management tasks related to managing transport servers? See Managing Transport Servers.

Internal Mail Flow

The Hub Transport server role processes all messages that are sent inside the Microsoft Exchange Server 2010 organization before the messages are delivered to a recipient's Inbox or are routed to users outside the organization. There are no exceptions to this behavior; messages are always passed through a server that runs the Hub Transport server role. Messages are submitted to the Hub Transport server in three ways: through SMTP submission, from the Pickup directory, or when a user inside the organization sends a message, which is picked up from the user's Outbox by the store driver. The store driver is a software component of the Hub Transport server that delivers inbound messages to Exchange stores, the databases that contain public folder and mailbox stores. When messages are submitted to the Hub Transport server, they're processed by the categorizer. The categorizer is a component of Exchange transport that processes all inbound messages and determines what to do with the messages based on information about the intended recipients. In Exchange 2010, the Hub Transport server uses the categorizer to expand distribution lists and to identify alternative recipients and forwarding addresses. After the categorizer retrieves full information about the recipients, it uses that information to apply policies, route the messages, and perform content conversion. Messages are then delivered locally by the store driver to a recipient's mailbox, or they're delivered remotely by using SMTP to send messages to another transport server. Messages that are sent by users in your organization are picked up from the sender's Outbox by the store driver and are put in the Submission queue on a server that runs the Hub Transport server role. For more information, see Understanding Transport Pipeline.

Messaging Policy and Compliance Features

With a collection of transport agents, you can configure rules and settings that are applied as messages enter and leave the mail flow components. You can create messaging policy and rule settings that are designed to meet different regulations and that can easily be changed to adapt to your organization's requirements. The transport-based messaging policy and compliance features include server-based rules that you configure to enforce your organization's compliance scenarios and the Journaling agent that acts to enforce message retention. For more information, see Planning for Compliance.

Anti-Spam and Antivirus Protection

Exchange 2010 provides anti-spam and antivirus protection for messages. Although these features are designed for use in the perimeter network on the Edge Transport server role, the Edge Transport agents can also be configured on the Hub Transport server. By default, these agents aren't enabled on the Hub Transport server role. To use the anti-spam features on the Hub Transport server, you must register the agents in a configuration file and enable the features that you want to use by running a provided Exchange Management Shell script. You install and enable the antivirus agent in a separate operation. For more information, see Understanding Anti-Spam and Antivirus Functionality.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Accepted Domains

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-11-23 An accepted domain is any SMTP namespace for which a Microsoft Exchange organization sends or receives e-mail. Accepted domains include those domains for which the Exchange organization is authoritative. An Exchange organization is authoritative when it handles mail delivery for recipients in the accepted domain. Accepted domains also include domains for which the Exchange organization receives mail and then relays it to an e-mail server that's outside the Active Directory forest for delivery to the recipient. Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents Configuring Accepted Domains Authoritative Domains Relay Domains Accepted Domains and E-Mail Address Policies

Configuring Accepted Domains

Accepted domains are configured as global settings for the Exchange organization and on computers that have the Edge Transport server role installed. You must configure every domain for which your Hub Transport servers relay or deliver messages as an accepted domain in your organization. The Edge Transport server requires that all domains for which it accepts and relays messages are configured as accepted domains. We recommend that you create and manage all accepted domains inside the organization and synchronize that information to the Edge Transport server by creating an Edge Subscription. When you subscribe the Edge Transport server to the Microsoft Exchange Server 2010 organization, all accepted domains that are configured in the organizational settings for the Hub Transport server role are replicated to the Edge Transport server during EdgeSync synchronization. To modify the accepted domain configuration on an Edge Transport server that's subscribed to the Exchange 2010 organization, you must make the change on the Hub Transport server. There are three types of accepted domains: authoritative, internal relay, and external relay. These accepted domain types are described in the following sections. Return to top

Authoritative Domains
An organization may have more than one SMTP domain. The set of e-mail domains for an organization are the authoritative domains. In Exchange 2010, an accepted domain is considered authoritative when the Exchange organization hosts mailboxes for recipients in this SMTP domain. The Edge Transport servers should always accept e-mail that's addressed to any of the organization's authoritative domains. By default, when the first Hub Transport server role is installed, one accepted domain is configured as authoritative for the Exchange organization. The default accepted domain is the fully qualified domain name (FQDN) for your forest root domain. Frequently, the internal domain name differs from the external domain name. For example, your internal domain name may be Contoso.local, although your external domain name is Contoso.com. The Domain Name System (DNS) mail exchange (MX) resource record for your organization references Contoso.com. Contoso.com is the SMTP namespace that you assign to users when you create an e-mail address policy. You must create an accepted domain to match your external domain name. By default, no accepted domains are configured on the Edge Transport server role. Return to top

Relay Domains
When e-mail is received from the Internet by an Edge Transport server and the recipient of the message isn't part of an authoritative domain, the sending server tries to relay through the Exchange server. When a server acts as a relay server that has no restrictions, it can put a large burden on Internet-connected servers. Administrators can prevent this open relay scenario by rejecting all e-mail that isn't addressed to a recipient in the organization's authoritative domains. However, there are scenarios where an organization wants to let partners or subsidiaries relay e-mail through the Exchange servers. In Exchange 2010, you can configure accepted domains as relay domains. Your organization receives the e-mail messages and then relays the messages to another e-mail server. You can configure a relay domain as an internal relay domain or as an external relay domain. These two relay domain types are described in the following sections.

Internal Relay Domain

When you configure an internal relay domain, some or all of the recipients in this domain don't have mailboxes in this Exchange organization. Mail from the Internet is relayed for this domain through Hub Transport servers in this Exchange organization. This configuration is used in the scenarios that are described in this section. An organization may have to share the same SMTP address space between two or more different e-mail systems. For example, you may have to share the SMTP address space between Microsoft Exchange and a third-party e-mail system, or between Exchange environments that are configured in different Active Directory

forests. In these scenarios, users in each e-mail system have the same domain suffix as part of their e-mail addresses. To support these scenarios, you must create an accepted domain that's configured as an internal relay domain. You must also add a Send connector that's sourced on a Hub Transport server and configured to send e-mail to the shared address space. If an accepted domain is configured as authoritative and a recipient isn't found in Active Directory, a non-delivery report (NDR) is returned to the sender. The accepted domain that's configured as an internal relay domain first tries to deliver to a recipient in the Exchange organization. If the recipient isn't found, the message is routed to the Send connector that has the closest address space match. If an organization contains more than one forest and has configured global address list (GAL) synchronization, the SMTP domain for one forest may be configured as an internal relay domain in a second forest. Messages from the Internet that are addressed to recipients in internal relay domains are received and processed by the Edge Transport server and then relayed to the Hub Transport servers in the same organization. The receiving Hub Transport servers then route the messages to the Hub Transport servers in the recipient forest. You configure the SMTP domain as an internal relay domain to make sure that e-mail that's addressed to that domain is accepted by the Exchange organization. The connector configuration of your organization determines how messages are routed. In the following figure, Fourthcoffee.com is configured as an internal relay domain for the Exchange 2010 organization in the Contoso.com forest. The MX resource records for Fourthcoffee.com reference a public IP address for the Contoso.com organization. A forest trust exists between Fourthcoffee.com and Contoso.com, and GAL synchronization is configured. The Contoso.com Edge Transport server accepts messages for the Fourthcoffee.com SMTP domain from the Internet and then relays those messages to the Hub Transport servers in the Contoso.com Exchange organization. The messages are then routed to the Hub Transport servers in the Fourthcoffee.com Exchange organization. A cross-forest Send connector is configured for routing messages from Contoso.com to Fourthcoffee.com. Messages that are sent from Fourthcoffee.com to external recipients are routed to the Hub Transport servers in the Contoso.com forest. A second cross-forest Send connector is configured for routing messages from Fourthcoffee.com to Contoso.com. When the Hub Transport servers in Contoso.com receive messages from the internal relay domain Fourthcoffee.com, they deliver messages for recipients in authoritative domains and relay messages for Internet recipients to the Edge Transport server for delivery.

External Relay Domain

When you configure an external relay domain, messages are relayed to an e-mail server that's outside the Exchange organization and outside the organization's network perimeter. The messages are relayed by the Edge Transport server. In this scenario, the MX resource record for the external relay domain references a public IP address for the Exchange 2010 organization that's relaying messages. The Edge Transport server receives the messages for recipients in the external relay domain and then routes the messages to the e-mail system for the external relay domain. A Send connector from the Edge Transport server to the external relay domain is required in this scenario. The external relay domain may also use your organization's Edge Transport server as a smart host for outgoing mail. In the following figure, Adatum.com is configured as an external relay domain for the Exchange 2010 organization in the Contoso.com forest. The MX resource record for Adatum.com references a public IP address for the Contoso.com organization. The Contoso.com Edge Transport server accepts messages for the Adatum.com SMTP domain from the Internet and then relays those messages to the e-mail servers in the Adatum.com organization. Adatum.com also uses the Contoso.com Edge Transport server as a smart host for routing outgoing messages. Messages that are sent from Adatum.com to external recipients are routed to the Edge Transport servers in the Contoso.com organization. When the Edge Transport servers in Contoso.com receive messages from Adatum.com, they deliver messages for recipients in authoritative domains and internal relay domains to the Hub Transport servers and route messages to the Internet.

Return to top

Accepted Domains and E-Mail Address Policies

You must configure an accepted domain before that SMTP address space can be used in an e-mail address policy. When you create an accepted domain, you can use a wildcard character (*) in the address space to indicate that all subdomains of the SMTP address space are also accepted by the Exchange organization. For example, to configure Contoso.com and all its subdomains as accepted domains, enter *.Contoso.com as the SMTP address space. The accepted domain entries are automatically available for use in an e-mail address policy. If you delete an accepted domain that's used in an e-mail address policy, the policy is no longer valid, and recipients with e-mail addresses in that SMTP domain will be unable to send or receive e-mail. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Address Rewriting

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-01-18 In Microsoft Exchange Server 2010, address rewriting enables you to modify the addresses of senders and recipients on messages that enter and leave your Exchange 2010 organization. Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents Why Use Address Rewriting Address Rewriting Scenarios SMTP Message Headers What Address Rewriting Agents Don't Rewrite Considerations for Use of Outbound-Only Address Rewriting Considerations for Bidirectional Address Rewriting Considerations for Rewriting Addresses in Multiple Domains Prioritization of Address Rewriting Entries Digitally Signed, Encrypted, and Rights-Protected Messages

Why Use Address Rewriting?

You use address rewriting to present a consistent appearance to external recipients of messages from your Exchange 2010 organization. Address rewriting can be valuable to organizations that use third-party vendors to provide e-mail support and services. Customers and partners expect e-mail messages to come from the organization, not a third-party vendor. Similarly, after a merger or acquisition, an organization might want all e-mail messages to appear to come from the single new organization. The address rewriting feature frees organizations to structure their businesses by business requirements instead of by technical requirements or limitations. You can also use address rewriting to enable appropriate routing of inbound messages from outside your Exchange 2010 organization to internal recipients. Address rewriting enables replies to messages that were rewritten to be correctly routed to the original sender of the rewritten message. You configure Address Rewriting agents on the Receive connector and Send connector on a computer that has the Edge Transport server role installed. Return to top

Address Rewriting Scenarios

The following scenarios are examples of how address rewriting can benefit organizations:

Group consolidation Some organizations segment their internal businesses into separate domains that are based on business or technical requirements. However, this configuration can cause e-mail messages to appear as if they come from separate groups or even separate organizations. This appearance might not be desirable to the organization. The following example shows how an organization, Contoso, Ltd., could hide its subdomains: Outbound messages from the Northamerica.contoso.com, Europe.contoso.com, and Asia.contoso.com domains are rewritten to appear as if they all originate from a single Contoso.com domain. All messages are rewritten as they pass through Edge Transport servers that provide SMTP connectivity between the whole organization and the Internet. Inbound messages to the Contoso.com domain are passed on by the Edge Transport server to the Hub Transport server role, which then determines the correct recipient. For example, messages to chris@contoso.com are sent to an internal Hub Transport server, which then determines the correct mailbox to send the message to by using the proxy address that's configured on the recipient's e-mail account. Mergers and acquisitions When organizations merge or are acquired, their technology infrastructure must be modified to match new business and technical requirements. An acquired company may continue to run as a separate business unit, but the e-mail administrator can use address rewriting to make the two organizations appear as if they're one integrated organization. The following example shows how Contoso, Ltd. could hide the e-mail domain of the newly acquired company, Fourth Coffee: Contoso, Ltd. wants all outbound messages from Fourth Coffee's Exchange organization to appear as if they originate from Contoso.com. All messages from both organizations are sent through the Edge Transport servers at Contoso, Ltd., where e-mail messages are rewritten from someone@fourthcoffee.com to someone@contoso.com. Inbound messages to adam@contoso.com are rewritten and routed to his adam@fourthcoffee.com e-mail account. Incoming messages that use his old adam@fourthcoffee.com domain are also accepted, because the domain still exists. Inbound replies to e-mail messages that were rewritten are handled by the Edge Transport servers at Contoso, Ltd., where the Address Rewriting agent rewrites the recipient address so that replies are correctly routed to the appropriate Fourthcoffee.com e-mail address. Replies to e-mail messages that were sent before the merger to Fourthcoffee.com e-mail addresses are routed directly to Fourth Coffee's e-mail servers. Partners Many organizations use external partners to provide services for their customers, other partners, or the organization itself. To avoid confusion, the organization might replace the e-mail domain of the partner organization with its own e-mail domain. The following example shows how Contoso, Ltd. could hide a partner's e-mail domain:

Contoso, Ltd. provides support for the larger Wingtip Toys organization. Wingtip Toys wants a unified experience for its customers and requires all messages that originate from support personnel at Contoso, Ltd. to appear as if they were sent from Wingtip Toys. All outbound messages that relate to Wingtip Toys are sent through their Edge Transport servers, and all Contoso.com addresses are rewritten to appear as Wingtiptoys.com addresses. Inbound messages for support@wingtiptoys.com are accepted by Wingtip Toy's Edge Transport servers, rewritten, and then routed to the support@contoso.com e-mail address. Caution: So that inbound e-mail is appropriately mapped and routed, you must make sure that the user name part of the address is unique across all e-mail organizations that may be affected by address rewriting. Return to top

SMTP Message Headers

Address Rewriting agents rewrite e-mail addresses by rewriting the SMTP headers on e-mail messages that are sent and received by an Edge Transport server. Address Rewriting agents typically rewrite outbound messages because the organization wants to hide the internal domains and subdomains as effectively as possible and present a single external domain to the Internet. Address Rewriting agents typically rewrite inbound messages to route those messages to their intended recipients. For these reasons, Address Rewriting agents rewrite several SMTP header fields on outbound e-mail messages. Address Rewriting agents rewrite only one SMTP header field on inbound e-mail messages. The following table shows which SMTP header fields are rewritten on outbound and inbound messages.

SMTP header fields rewritten on outbound and inbound messages

SMTP header field Envelope From (MAIL FROM) Envelope To (RCPT TO) Body To Body Cc Body From Body Sender Body Reply-To Body Return-Receipt-To Body Disposition-Notification-To Body Resent-From Body Resent-Sender Return to top Outbound Rewritten Not rewritten Rewritten Rewritten Rewritten Rewritten Rewritten Rewritten Rewritten Rewritten Rewritten Inbound Not rewritten Rewritten Not rewritten Not rewritten Not rewritten Not rewritten Not rewritten Not rewritten Not rewritten Not rewritten Not rewritten

What Address Rewriting Agents Don't Rewrite

Address Rewriting agents don't rewrite several SMTP header fields, because address rewriting would break SMTP functionality. For example, changing these SMTP headers could affect message loop detection, invalidate the signature, or make a rights-protected message unreadable. The following SMTP header fields aren't modified by the Address Rewriting agents:

Return-Path Received Message-ID X-MS-TNEF-Correlator Content-Type Boundary=string Headers located inside MIME body parts Address Rewriting agents also don't rewrite header fields within e-mail messages that contain domains for which the Hub Transport server isn't authoritative. Rewriting such domains causes an uncontrollable form of message relay. Address Rewriting agents also don't modify the header fields of messages that are embedded in another message. Senders and recipients expect embedded messages to remain intact and be delivered without modification, as long as the messages don't trigger transport rules that are implemented between the sender and recipient. Return to top

Considerations for Use of Outbound-Only Address Rewriting

When an e-mail message is outbound from the Exchange 2010 organization, outbound-only address rewriting involves modification of the sender SMTP address only. The Address Rewriting agent is configured only on the Send connector on the Edge Transport server. The following list shows the conditions that are required to configure an outbound-only Address Rewriting agent:

The resulting addresses must be unique across the organization. For example, if the unique e-mail addresses ed@sales.contoso.com and ed@research.contoso.com are included in a rule to rewrite all addresses to contoso.com, the Address Rewriting agent will rewrite both addresses to ed@contoso.com and will cause a conflict. A proxy address must be configured on each mailbox that matches the rewritten e-mail address. This enables those mailboxes to receive replies to e-mail messages in which headers are rewritten. When you use wildcard characters, there must be a period between the wildcard character and the domain name. You can use wildcard characters only in the internal domain. No characters can be in front of the wildcard character. Outbound-only address rewriting can't affect the user name or display name part of the address. Only literal strings are supported. Return to top

Considerations for Bidirectional Address Rewriting

Bidirectional address rewriting modifies the sender SMTP address on e-mail messages that are leaving the Exchange organization and the recipient SMTP address on email messages that are entering the Exchange organization. To do this, you configure the Address Rewriting agent on both the Send connector and Receive connector on the Edge Transport server. The following list shows the conditions that are required when you create a bidirectional Address Rewriting agent:

You can't use wildcard characters. You must use full SMTP addresses when you configure a bidirectional address rewriting rule. For example, the internal address is chris@contoso.com, and the external address is support@contoso.com. Only literal strings are supported. The address must be unique across the organization. For example, if an e-mail address, bob@contoso.com, already exists, mapping robert@fourthcoffee.com to bob@contoso.com will cause replies to messages from bob@contoso.com to be delivered to the wrong person. Return to top

Considerations for Rewriting Addresses in Multiple Domains

Before you create an address rewrite entry that rewrites multiple domains, you must prepare your subdomains. Also, before you perform the procedure for creating an address rewrite entry for multiple subdomains that's described in Create an Address Rewrite Entry, you must understand the requirements for rewriting e-mail addresses in multiple domains to a single domain, and the appropriate preconfiguration for the affected mailboxes and contacts.

Important Considerations
When you flatten internal subdomains into a single external domain, you must consider the following factors, which apply only when multiple subdomains are being rewritten:

Unique aliases are required All e-mail aliases, the part of the e-mail address to the left of the at (@) sign, must be unique across all subdomains. For example, if there is a joe@sales.contoso.com, there can't be a joe@marketing.contoso.com. Proxy addresses are required A proxy address that matches the e-mail address that's produced by the Address Rewriting agent must be configured on every e-mail account that's in the subdomains that are rewritten. For example, if joe@sales.contoso.com is rewritten to joe@contoso.com, the e-mail address joe@contoso.com must be added as a proxy address to Joe's mailbox. Contacts may be required If you're rewriting e-mail from a non-Exchange 2010 e-mail system, you must create Active Directory mail-enabled contacts for each e-mail address in the non-Exchange 2010 e-mail address that's being rewritten. This mail-enabled contact must contain the original e-mail address and the rewritten e-mail address. For example, if joe@unix.contoso.com is rewritten to joe@contoso.com, you must create a mail-enabled contact in Active Directory with joe@unix.contoso.com as the target SMTP address and joe@contoso.com as the proxy SMTP address. These factors are important because rewriting addresses in multiple subdomains causes a many-to-one relationship between internal subdomains and the externally visible domain. Because of this many-to-one relationship, the Address Rewriting agent can't determine which subdomain contains the correct recipient when a message that's addressed to the externally visible domain is received. Important: Make sure that every e-mail alias that exists across all subdomains is unique. Exchange 2010 doesn't check to verify that every e-mail alias that can be rewritten to a single domain is unique.

Removing Conflicting E-Mail Addresses

To create an address rewrite entry that rewrites multiple subdomains, you must first make sure that all e-mail aliases are unique across all your subdomains. For example, consider the following configuration: The following users are in the subdomains sales.contoso.com, marketing.contoso.com and research.contoso.com:

maria@sales.contoso.com chris@sales.contoso.com david@marketing.contoso.com brian@marketing.contoso.com chris@research.contoso.com adam@research.contoso.com Each subdomain has two users, and each user has a unique e-mail address. However, you want to rewrite the subdomains sales.contoso.com, marketing.contoso.com, and research.contoso.com into a single domain that's called contoso.com. The following table shows each original e-mail address and its corresponding rewritten email address.

Original e-mail addresses and corresponding rewritten e-mail addresses

Original e-mail address maria@sales.contoso.com chris@sales.contoso.com david@marketing.contoso.com brian@marketing.contoso.com chris@research.contoso.com adam@research.contoso.com Rewritten e-mail address maria@contoso.com chris@contoso.com david@contoso.com brian@contoso.com chris@contoso.com adam@contoso.com

When the e-mail addresses in each subdomain are rewritten, a conflict occurs between chris@sales.contoso.com and chris@research.contoso.com. Therefore, both email addresses are rewritten to chris@contoso.com. To resolve this situation, you must change the e-mail address of one of the recipient mailboxes to an address that doesn't conflict with the e-mail address in any other subdomain.

Applying Proxy Addresses to Recipient Mailboxes

For internal recipient mailboxes to receive replies to addresses that have been rewritten, you must configure those recipient mailboxes by using a proxy address that matches the rewritten external address. For example, if a mailbox exists for adam@research.contoso.com, and the rewritten external address is adam@contoso.com, the mailbox must be configured by using a proxy address that's set to adam@contoso.com. Return to top

Prioritization of Address Rewriting Entries

The rule that best matches the internal and external domain pair is applied. The following prioritization is the exact order of address rewriting entries from highest priority to lowest priority:

1. Individual e-mail addresses An example is mapping john@contoso.com to support@contoso.com. 2. Specific domain or subdomain mapping An example is mapping Contoso.com to Northwindtraders.com or Sales.contoso.com to Contoso.com. 3. Domain flattening An example is flattening *.contoso.com into Contoso.com. For example, the following two rules are configured on the Edge Transport server:

*.contoso.com maps to Contoso.com Japan.sales.contoso.com maps to contoso.jp

If masato@japan.sales.contoso.com sends an e-mail message, the address is rewritten as masato@contoso.jp, because that rule most closely matches the sender's internal domain, even though the *.contoso.com rule is present. Return to top

Digitally Signed, Encrypted, and Rights-Protected Messages

Address rewriting shouldn't affect most signed, encrypted, or rights-protected messages. If address rewriting were to invalidate a signature, make an encrypted or rights-protected message unreadable, or otherwise change the security status of such messages in any way, address rewriting isn't applied. Addresses and information in the following message sections can be rewritten, because information in these sections isn't part of message signing, encryption, or rights protection:

SMTP envelope fields Top-level message body headers Addresses and information in the following message sections isn't rewritten because information in these sections is part of message signing, encryption, or rights protection:

Headers located inside MIME body parts that may be signed The boundary string parameter of the MIME content type Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Anti-Spam and Antivirus Functionality

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-01-18 Spammers, or malicious senders, use a variety of techniques to send spam into your organization. No single tool or process can eliminate all spam. Microsoft Exchange Server 2010 builds on the foundation of Exchange Server 2007 to provide a layered, multipronged, and multifaceted approach to reducing spam and viruses. Exchange 2010 includes a variety of anti-spam and antivirus features that are designed to work cumulatively to reduce the spam that enters your organization. You can reduce the incidences of virus outbreaks and attacks by malicious software, which is also referred to as malware, in your organization if you reduce the overall volume of spam that enters your organization. When you eliminate the bulk of the spam at the computer that has the Edge Transport server role installed, you save processing resources, bandwidth, and storage when the messages are scanned for viruses and other malware further along the mail flow path. The layered approach to reducing spam refers to the configuration of several anti-spam and antivirus features that filter inbound messages in a specific order. Each feature filters for a specific characteristic or set of related characteristics on the inbound message. The following sections provide brief descriptions of each default anti-spam and antivirus feature. Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents Anti-Spam and Antivirus Filters Anti-Spam Stamps Microsoft Update for Anti-Spam Services Using Exchange Hosted Services Strategy for Anti-Spam Approach

Anti-Spam and Antivirus Filters

The anti-spam and antivirus filters are applied in a specific order. For more information, see Understanding Anti-Spam and Antivirus Mail Flow. The following order applies:

1. Connection filtering Connection filtering inspects the IP address of the remote server that's trying to send messages to determine what action, if any, to take on an inbound message. The remote IP address is available to the Connection Filter agent as a byproduct of the underlying TCP/IP connection that's required for the SMTP session. Connection filtering uses a variety of IP Block lists, IP Allow lists, as well as IP Block List provider services or IP Allow List provider services to determine whether the connection from the specific IP should be blocked or allowed in the organization. 2. Sender filtering Sender filtering compares the sender on the MAIL FROM: SMTP command to an administrator-defined list of senders or sender domains who are prohibited from sending messages to the organization to determine what action, if any, to take on an inbound message. 3. Recipient filtering Recipient filtering compares the message recipients on the RCPT TO: SMTP command to an administrator-defined Recipient Block list. If a match is found, the message isn't permitted to enter the organization. The recipient filter also compares recipients on inbound messages to the local recipient directory to determine whether the message is addressed to valid recipients. When a message isn't addressed to valid recipients, the message can be rejected at the organization's network perimeter. 4. Sender ID Sender ID relies on the IP address of the sending server and the Purported Responsible Address (PRA) of the sender to determine whether the sender is spoofed or not. PRA is calculated based on the following message headers: Resent-Sender: Resent-From: Sender: From: For more information about the PRA, see Understanding Sender ID and RFC 4407. 5. Content filtering Content filtering uses Microsoft SmartScreen technology to assess the contents of a message. Intelligent Message Filter is the underlying technology of Exchange content filtering. Intelligent Message Filter is based on patented machine-learning technology from Microsoft Research. During its development, Intelligent Message Filter learned distinguishing characteristics of legitimate e-mail messages and spam. Regular updates with Microsoft Exchange Anti-spam Update service ensure that the most up-to-date information is always included when the Intelligent Message Filter runs. Based on the characteristics of millions of messages, Intelligent Message Filter recognizes indicators of both legitimate messages and spam messages. Intelligent Message Filter can accurately assess the probability that an inbound e-mail message is either a legitimate message or spam. Spam quarantine is a feature of the Content Filter agent that reduces the risk of losing legitimate messages that are incorrectly classified as spam. Spam quarantine provides a temporary storage location for messages that are identified as spam and that shouldn't be delivered to a user mailbox inside the organization. Content filtering also acts on the safelist aggregation feature. Safelist aggregation collects data from the anti-spam safe lists that Microsoft Outlook and Outlook Web App users configure and makes this data available to the Content Filter agent on the computer that has the Edge Transport server role installed in Exchange 2010. When an Exchange administrator enables and correctly configures safelist aggregation, the Content Filter agent passes safe e-mail messages to the enterprise mailbox without additional processing. E-mail messages that Outlook users receive from contacts or that those users have added to their Outlook Safe Senders List or have trusted are identified by the Content Filter agent as safe. The result is that messages that are identified as safe aren't classified as spam and unintentionally filtered out of the messaging system. 6. Sender reputation Sender reputation relies on persisted data about the IP address of the sending server to determine what action, if any, to take on an inbound message. The Protocol Analysis agent is the underlying agent that implements the sender reputation functionality. A sender reputation level (SRL) is calculated from several sender characteristics that are derived from message analysis and external tests. Senders whose SRL exceeds a configurable threshold will be temporarily blocked. All their future connections are rejected for up to 48 hours. In addition to the locally calculated IP reputation, Exchange 2010 also takes advantage of IP reputation anti-spam updates, available via Microsoft Update, which provide sender reputation information about IP addresses that are known to send spam. 7. Attachment filtering Attachment filtering filters messages based on attachment file name, file name extension, or file MIME content type. You can configure

attachment filtering to block a message and its attachment, to strip the attachment and allow the message to pass through, or to silently delete the message and its attachment. 8. Microsoft Forefront Protection 2010 for Exchange Server Forefront Protection 2010 for Exchange Server (FPE) is an antivirus software package that's tightly integrated with Exchange 2010 and offers antivirus protection for the Exchange environment. The antivirus protection that's provided by FPE is language independent. However, the setup, administration of the product, and end-user notifications are available in 11 server languages. For more information, see Microsoft Forefront Protection 2010 for Exchange Server. 9. Outlook junk e-mail filtering The Outlook junk e-mail filter uses state-of-the-art technology to evaluate whether a message should be treated as a junk email message based on several factors, such as the time that the message was sent, the content and structure of the message, and the metadata collected by the Exchange Server anti-spam filters. Messages caught by the filter are moved to a special Junk E-mail folder, where the recipient can access them later. Return to top

Anti-Spam Stamps
Anti-spam stamps help you diagnose spam-related problems by applying diagnostic metadata, or stamps, such as sender-specific information, puzzle validation results, and content filtering results, to messages as they pass through the anti-spam features that filter inbound messages from the Internet. These stamps are visible to the end-user mail client and encode sender-specific information, the version of the spam filter definition file, Outlook puzzle validation results, and content filtering results. Return to top

Microsoft Update for Anti-Spam Services

Exchange 2010 offers additional services to help keep anti-spam components up to date, taking advantage of the proven Microsoft Update infrastructure. Microsoft Exchange 2010 Standard Anti-spam Filter Updates offer anti-spam updates every two weeks via Microsoft Update. The Forefront Security for Exchange Server Anti-spam Update service is a premium service that updates the content filter daily via Microsoft Update. In addition, the premium service includes the spam signature and IP Reputation Service updates that are available on an as-needed basis, up to several times a day. Spam signature updates identify the most recent spam campaigns. IP Reputation Service updates provide sender reputation information about IP addresses that are known to send spam. Note: To use the premium service, you must have the Exchange Enterprise client access license (CAL). Return to top

Using Exchange Hosted Services

Spam filtering is enhanced by or is also available as a service from Microsoft Exchange Hosted Services. Exchange Hosted Services is a set of four distinct hosted services:

Hosted Filtering, which helps organizations protect themselves from e-mail-borne malware Hosted Archive, which helps them satisfy retention requirements for compliance Hosted Encryption, which helps them encrypt data to preserve confidentiality Hosted Continuity, which helps them preserve access to e-mail during and after emergency situations These services integrate with any on-premises Exchange servers that are managed in-house or Hosted Exchange e-mail services that are offered through service providers. For more information about Exchange Hosted Services, see Microsoft Exchange Hosted Services. Return to top

Strategy for Anti-Spam Approach

Your strategy for how to configure the anti-spam features and establish the aggressiveness of your anti-spam agent settings requires that you plan and calculate carefully. If you set all anti-spam filters to their most aggressive levels and configure all anti-spam features to reject all suspicious messages, you're more likely to reject messages that aren't spam. On the other hand, if you don't set the anti-spam filters at a sufficiently aggressive level and don't set the spam confidence level (SCL) threshold low enough, you probably won't see a reduction in the spam that enters your organization. It's a best practice to reject a message when Exchange detects a bad message through the Connection Filter agent, Recipient Filter agent, or Sender Filter agent. This approach is better than quarantining such messages or assigning metadata, such as anti-spam stamps, to such messages. The Connection Filter agent and Recipient Filter agent automatically block messages that are identified by the respective filters. The Sender Filter agent is configurable. This best practice is recommended because the SCL that underlies connection filtering, recipient filtering, or sender filtering is relatively high. For example, with sender filtering, where the administrator has configured specific senders to block, there's no reason to assign the sender filtering data to such messages and to continue to process them. In most organizations, blocked messages should be rejected. (If you didn't want the messages rejected, you wouldn't have put them on the Blocked Senders List.) The same logic applies to real-time block list services and recipient filtering, although the underlying confidence isn't as high as the IP Block list. You should be aware that the further along the mail flow path a message travels, the greater the probability of false positives, because the anti-spam features are evaluating more variables. Therefore, you may find that if you configure the first several anti-spam features in the anti-spam chain more aggressively, you can reduce the bulk of your spam. As a result, you'll save processing, bandwidth, and disk resources so that you can process more ambiguous messages. Ultimately, you must plan to monitor the overall effectiveness of the anti-spam features. If you monitor carefully, you can continue to adjust the anti-spam features to work well together for your environment. With this approach, you should plan on a fairly non-aggressive configuration of the anti-spam features when you start. This

approach lets you minimize the number of false positives. As you monitor and adjust the anti-spam features, you can become more aggressive about the type of spam and spam attacks that your organization experiences. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Anti-Spam and Antivirus Mail Flow

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-07-07 When an external user sends e-mail messages to a server running Microsoft Exchange that runs the anti-spam features, the anti-spam features cumulatively evaluate characteristics of inbound messages and either filter out messages suspected to be spam or assign messages a rating based on the probability that the message is spam. This rating is stored with the message as a message property called the spam confidence level (SCL) rating. This rating is persisted with the message when the message is sent to other Exchange servers. The following figure shows the order in which the default anti-spam features and Microsoft Forefront Protection for Exchange Server filter inbound messages from the Internet. By default, the anti-spam and antivirus features are arranged in this order with the filters that use the least resources filtering first, and then the filters that use the greatest resources filtering last. Note: The following figures and explanations assume that the Microsoft Exchange Server 2010 Edge Transport server is the first SMTP server to accept inbound messages. In some organizations, the Edge Transport server may be deployed behind a third-party SMTP server. When the Exchange 2010 Edge Transport server is deployed behind a third-party SMTP gateway server, the Exchange 2010 Edge Transport server requires additional configuration. Specifically, you must make sure that all SMTP gateway servers are listed in the InternalSMTPServer property of the TransportConfig object. For more information, see Set-TransportConfig. For more information about additional Exchange anti-spam and antivirus features, see Microsoft Forefront Protection 2010 for Exchange Server.

As shown in the preceding figure, when an SMTP server connects to Exchange 2010 and initiates an SMTP session, filters are applied in the following order when the Edge Transport server is Internet-facing:

Connection filtering Sender filtering Recipient filtering Sender ID filtering Content filtering Sender reputation filtering Attachment filtering Antivirus scanning Outlook junk e-mail filtering Note: Connection filtering gathers information during two different events. In the first event, connection filtering gathers IP address information from the connection (shown in the preceding figure). In the second event, connection filtering gathers information when the Sender Filter agent parses the message headers to determine the first external IP address (shown in the figure in "Sender Filtering" later in this topic). Agents may monitor multiple events. The preceding figure shows a high-level view of the approximate order in which agents are applied, when all agents are enabled, for the purposes of illustrating message flow. For more information about specific events and which agents monitor which events, see Understanding Transport Agents. Looking for management tasks related to anti-spam and antivirus functionality? See Managing Anti-Spam and Antivirus Features. Contents Connection Filtering Sender Filtering Recipient Filtering Sender ID Filtering Content Filtering Sender Reputation Filtering Attachment Filtering Antivirus Scanning Outlook Junk E-Mail Filtering

Connection Filtering

During the SMTP session, Exchange 2010 applies connection filtering by using the criteria shown in the following figure.

The following process applies:

1. The Connection Filter agent examines the administrator-defined IP Allow list. If the IP address of the sending server is on the administrator-defined IP Allow list, the message is then processed by sender filtering. 2. The Connection Filter agent examines the local IP Block list. If the IP address of the sending server is found on the local IP Block list, the message is automatically rejected, and no other filters are applied. 3. The Connection Filter agent examines the list of allowed IP addresses from any IP Allow List providers that you have. If the IP address of the sending server is on the list of allowed IP addresses from the IP Allow List providers, the message is then processed by sender filtering. 4. The Connection Filter agent examines the real-time block lists of any IP Block List providers that you've configured. If the sending server's IP address is found on a real-time block list, the message is rejected, and no other filters are applied. For more information, see Understanding Connection Filtering. Note: If the Connection Filter agent is deployed on a computer behind another server that faces the Internet, other filters, such as sender filtering and recipient filtering, are invoked before the Connection Filter agent. Return to top

Sender Filtering
After connection filtering has been applied, Exchange 2010 examines the sender e-mail address against the list of blocked senders that you configure in sender filtering as shown in the following figure.

The Sender Filter agent then checks the sender's e-mail address contained in the From header fields in the message envelope and the message header. If either From header field matches the address in the Blocked Sender list, Exchange 2010 rejects the message at the protocol level, and no other filters are applied. Note: Even if recipients in your organization have put senders on their Microsoft Outlook Safe Senders List, sender filtering on the Edge Transport server will override the recipient's Outlook setting and reject the messages. For more information about sender filtering, see Understanding Sender Filtering. For more information about message envelopes and message headers, see Understanding the Pickup and Replay Directories. Return to top

Recipient Filtering
If sender filtering doesn't reject the message, Exchange runs connection filtering again. Exchange then applies the Recipient Filter agent as shown in the following figure.

The Recipient Filter agent examines the recipient against the Recipient Block list that you configure in the Recipient Filter agent settings. If the intended recipient matches an e-mail address on your Recipient Block list, Exchange 2010 rejects the message for that particular recipient. In addition, the Recipient Filter agent checks whether the recipient is present in the organization. If the recipient isn't present in the organization, Exchange rejects the message for that particular recipient. If multiple recipients are listed on the message and all the recipients aren't on the Recipient Block list, the message will continue to process. Otherwise, if the message is bound for only a single blocked recipient, no other filters are applied. When a message with blocked recipients is processed, the set of blocked recipients are removed from the message, and the message continues into the organization. Protocol-level SMTP rejection responses are sent to the sender for each blocked recipient. The Sender Reputation agent monitors the OnReject event to calculate sender reputation level (SRL). For more information, see Understanding Recipient Filtering. Return to top

Sender ID Filtering
If the message still contains valid recipients after recipient filtering has been applied, Exchange 2010 runs the Sender ID agent as shown in the following figure.

First, the Sender ID agent determines the Purported Responsible Address (PRA) of the message using the algorithm described in RFC 4407. This step is required to accurately identify the message sender. The PRA is an SMTP address, such as kim@contoso.com. The Sender ID agent then performs a Domain Name System (DNS) lookup against the domain part of the PRA. If that domain has published a sender policy framework (SPF) record, the agent uses the SPF record to evaluate the message according to the specification for RFC 4408. The result of the evaluation is stamped on the message in the anti-spam stamp. If that domain doesn't have a published SPF record, the Sender ID agent stamps a Sender ID result of "None" on the message. For more information about the types of stamps used for Sender ID filtering, see Understanding Anti-Spam Stamps. If the sender's DNS is from a blocked domain or a blocked address, the following actions may be taken depending on your configuration of Sender ID actions:

Reject message If the Sender ID action is set to Reject Message, Exchange rejects the message and sends an SMTP error response to the sending server. The SMTP error response is a 5xx level protocol response with text that corresponds to the Sender ID status. Delete message If the Sender ID action is set to Delete Message, Exchange deletes the message without informing the sending server of the deletion. The computer that has the Edge Transport server role installed sends a fake "OK" SMTP command to the sending server, and then deletes the message. Because the sending server assumes that the message was sent, the sending server won't retry sending the message in the same session. Stamp message with Sender ID result and continue processing Exchange stamps the message with the Sender ID result and continues processing the message. This metadata is evaluated by the Content Filter agent when an SCL is calculated. Additionally, sender reputation uses the message metadata when it calculates an SRL for the sender of the message. For more information, see Understanding Sender ID. Return to top

Content Filtering
Before Exchange content filtering calls the Exchange Intelligent Message Filter, it applies sender filtering again. The Exchange server then applies the Content Filter agent as shown in the following figure.

The Content Filter agent checks the following conditions in the message. If any of the conditions are true, the message bypasses content filtering and attachment filtering. These messages then go to antivirus scanning for processing. The following conditions are checked:

The sender's IP address is on the IP Allow list for connection filtering. All recipients are on the exceptions list for content filtering. The AntiSpamBypassEnabled parameter is set to $True on all the recipients' mailboxes. All the recipients have added this sender to their Outlook Safe Senders List, which is updated to the Edge Transport server by using safelist aggregation. The sender is a trusted partner and on the organization's list of senders that aren't filtered. In addition to the conditions listed, if the SMTP session has been authenticated as a trusted partner, and if the administrator has granted the Bypass Anti-Spam (MsExch-Bypass-Anti-Spam) permission to partners, the anti-spam agents will be disabled for messages during that session. The Bypass Anti-Spam permission isn't granted to partners by default and must be assigned by an administrator. If a message doesn't meet any of the conditions described, content filtering is applied. Content filtering assigns an SCL rating to the message. Based on the SCL rating, one of the following actions occurs:

If the SCL rating on the message is equal to or greater than the SCL delete threshold, and the SCL delete threshold is enabled, the Content Filter agent deletes the message. There is no protocol-level communication that tells the sending system or sender that the message was deleted. If the SCL rating is lower than the SCL

delete threshold value, the Content Filter agent doesn't delete the message. Instead, the Content Filter agent compares the SCL value to the SCL reject threshold. If the SCL rating on the message is equal to or greater than the SCL reject threshold, and the SCL reject threshold is enabled, the Content Filter agent rejects the message and sends a rejection response to the sending system. You can customize the rejection response. In some cases, a non-delivery report (NDR) is sent to the original sender of the message. If the SCL rating is lower than the SCL reject threshold value, the Content Filter agent doesn't reject the message. Instead, the Content Filter agent compares the SCL value to the SCL quarantine threshold. If the SCL rating on the message is equal to or greater than the SCL quarantine threshold, and the SCL quarantine threshold is enabled, the Content Filter agent sends the message to the spam quarantine mailbox. For more information about how to manage the spam quarantine mailbox, see Understanding Content Filtering. The message then continues to attachment filtering. For more information, see the following topics:

Configure Safelist Aggregation Understanding Content Filtering Return to top

Sender Reputation Filtering

After content filtering has been applied, Exchange applies sender reputation filtering as shown in the following figure.

Sender reputation weighs each of the following message statistics and calculates an SRL for each sender:

HELO/EHLO analysis Reverse DNS lookup Analysis of SCL ratings on messages from a specific sender Sender open proxy test The SRL is a number from 0 through 9 that predicts the probability that a specific sender is a spammer or otherwise malicious user. A value of 0 indicates that the sender isn't likely to be a spammer; a value of 9 indicates that the sender is likely to be a spammer. You can configure an SRL block threshold from 0 through 9 by which sender reputation issues a request to the Sender Filter agent to block the sender from sending a message into the organization. When a sender is blocked, the sender is added to the Blocked Senders list for a configurable period. How blocked messages are handled depends on the configuration of the Sender Filter agent. The following actions are the options for handling blocked messages:

Reject Delete and archive Accept and mark as a blocked sender If a sender is included in the IP Block list or Microsoft IP Reputation Service, the Sender Reputation agent issues an immediate request to the Sender Filter agent to block the sender. To take advantage of this functionality, you must enable and configure the Microsoft Exchange Anti-spam Update Service. By default, the Edge Transport server sets a rating of 0 for senders that haven't been analyzed. After a sender has sent 20 or more messages, sender reputation calculates an SRL that's based on the statistics listed earlier. For more information, see the following topics:

Understanding Sender Reputation Configure Sender Reputation Properties Return to top

Attachment Filtering
After sender reputation filtering has been applied, Exchange applies attachment filtering as shown in the following figure.

You can configure attachment filtering to block attachments based on their MIME content type, file name, or file name extension. If attachment filtering detects a content type or file name that has been blocked, one of the following actions will occur based on your attachment filtering settings:

Reject If the action setting is set to Reject, both the e-mail message and attachment are prevented from being delivered to the recipient and the system generates a delivery status notification (DSN) failure message to the sender. You can customize your rejection response. Silent Delete If the action setting is set to Silent Delete, both the e-mail message and attachment are prevented from being delivered to the recipient. A notification that the e-mail message and attachment were blocked isn't returned to the sender. Strip If the action setting is set to Strip, the attachment is stripped from the e-mail message. This value allows the message and other attachments that don't match an entry on the attachment block list to be delivered to the recipient. A notification that the attachment was blocked is added to the recipient's e-mail message. If the message wasn't rejected or deleted, or attachment filtering didn't detect blocked attachment types, the message is then scanned for viruses. For more information, see Configure Attachment Filtering. Return to top

Antivirus Scanning
After attachment filtering has been applied, or if the recipients were bypassed in content filtering, Forefront Protection for Exchange Server antivirus scanning is applied as shown in the following figure.

Forefront Protection for Exchange Server is an antivirus software package that's tightly integrated with Exchange 2010 and offers additional antivirus protection for your Exchange environment. When Forefront Protection for Exchange Server detects messages that seem to contain a virus, the system deletes the message, generates a notification message, and sends the notification to the recipients mailbox. For more information, see Microsoft Forefront Protection 2010 for Exchange Server. Return to top

Outlook Junk E-Mail Filtering

After all the filters are applied and the message has been scanned for viruses, the message is sent to the intended recipient's mailbox and junk e-mail filtering is applied as shown in the following figure.

If the SCL rating for the message is equal to or greater than the SCL Junk E-mail folder threshold, and the SCL Junk E-mail folder threshold is enabled, the Mailbox server puts the message in the Outlook user's Junk E-mail folder. If the SCL value for a message is lower than the values for the SCL delete, reject, quarantine, and Junk E-mail folder thresholds, the Mailbox server puts the message in the user's Inbox. For more information about the SCL thresholds, see Understanding Spam Confidence Level Threshold. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Anti-Spam Stamps

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-01-28 In Microsoft Exchange Server 2010, anti-spam stamps help you diagnose spam-related problems by applying diagnostic metadata, or stamps, such as sender-specific information, puzzle validation results, and content filtering results, to messages as they pass through the anti-spam features that filter inbound messages from the Internet. There are three anti-spam stamps: the phishing confidence level stamp, the spam confidence level stamp, and the Sender ID stamp. This topic explains how to view anti-spam stamps and describes the contents of the anti-spam report. You can use anti-spam stamps as diagnostic tools to determine what actions to take on false-positives and on suspected spam messages that individuals receive in their mailboxes. Looking for management tasks related to managing transport servers? See Managing Transport Servers.

Viewing Anti-Spam Stamps

You can view anti-spam stamps by using Microsoft Office Outlook 2007. For more information about how to view anti-spam stamps, see View Anti-Spam Stamps in Outlook 2010 and Outlook 2007.

Understanding the Anti-Spam Report

The anti-spam report is a summary report of the anti-spam filter results that have been applied to an e-mail message. The Content Filter agent applies this stamp to the message envelope in the form of an X-header as follows.

X-MS-Exchange-Organization-Antispam-Report: DV:<DATVersion>;CW:CustomList;PCL:PhishingVerdict <verdict>;P100:PhishingBlock;PP:Presolve;SID:SenderIDSt

The following table describes the filter information that can appear in an anti-spam report. Note: The anti-spam report only displays information from the filters that were applied to the specific message. An anti-spam report doesn't usually contain all the information listed in the following table. For example, you may receive the following anti-spam report: DV:3.1.3924.1409;SID:SenderIDStatus Fail;PCL:PhishingLevel SUSPICIOUS;CW:CustomList;PP:Presolved;TIME:TimeBasedFeatures.

Filter information in an anti-spam report

Stamp SID Description The Sender ID (SID) stamp is based on the sender policy framework (SPF) that authorizes the use of domains in e-mail. The SPF is displayed in the message envelope as Received-SPF. The Sender ID evaluation process generates a Sender ID status for the message. This status can be returned as one of the following values: Pass Both the IP address and Purported Responsible Address (PRA) passed the Sender ID verification check. Neutral Published Sender ID data is explicitly inconclusive. Soft fail The IP address for the PRA may be in the not permitted set. Fail The IP Address is not permitted; no PRA is found in the incoming mail or the sending domain does not exist. None No published SPF data exists in the sender's DNS. TempError A temporary DNS failure occurred, such as an unavailable DNS server. PermError The DNS record is invalid, such as an error in the record format. The Sender ID stamp is displayed as an X-Header in the message envelope as follows:

X-MS-Exchange-Organization-SenderIdResult:<status>

For more information about Sender ID, see Understanding Sender ID. DV SA The DAT version (DV) stamp indicates the version of the spam definition file that was used when scanning the message. The signature action (SA) stamp indicates that the message was either recovered or deleted because of a signature that was found in the message. The signature DAT version (SV) stamp indicates the version of the signature file that was used when scanning the message. The phishing confidence level (PCL) stamp displays the rating of the message based on its content and is applied when the message is processed by the Content Filter agent. This status can be returned as one of the following values: Neutral The message's content isn't likely to be phishing. Suspicious The message's content is likely to be phishing.

SV PCL

The PCL value can range from 1 through 8. A PCL rating from 1 through 3 returns a status of Neutral. This means that the message's content isn't likely to be phishing. A PCL rating from 4 through 8 returns a status of Suspicious. This means that the message is likely to be phishing. The values are used to determine what action Outlook takes on messages. Outlook uses the PCL stamp to block the content of suspicious messages. The PCL stamp is displayed as an X-header in the message envelope as follows:

X-MS-Exchange-Organization-PCL:<status>

SCL

The spam confidence level (SCL) stamp of the message displays the rating of the message based on its content. The Content Filter agent uses Microsoft SmartScreen technology to assess the contents of a message and to assign an SCL rating to each message. The SCL value is from 0 through 9, where 0 is considered less likely to be spam, and 9 is considered more likely to be spam. The actions that Exchange and Outlook take depend on your SCL threshold settings. The SCL stamp is displayed as an X-header in the message envelope as follows:

X-MS-Exchange-Organization-SCL:<status>

For more information about SCL thresholds and actions, see Understanding Spam Confidence Level Threshold. CW The custom weight (CW) stamp of a message indicates that the message contains an unapproved word or phrase and that the SCL value, or weight, of that unapproved word or phrase was applied to the final SCL score: Unapproved phrases, or Block phrases, have maximum weight and change the SCL score to 9. Approved words or phrases, or Allow phrases, have minimum weight and change the SCL score to 0. For more information about how to add approved and unapproved words or phrases to the Content Filtering agent, see Configure Content Filtering Properties. PP The presolved puzzle (PP) stamp indicates that if a sender's message contains a valid, solved computational postmark, based on Outlook E-mail Postmark validation functionality, it's unlikely that the sender is a malicious sender. In this case, the Content Filter agent would reduce the SCL rating. The Content Filter agent doesn't change the SCL rating if the E-mail Postmark validation feature is enabled and either of the following conditions is true: An inbound message doesn't contain a computational postmark header. The computational postmark header isn't valid. For more information about the postmark validation feature, see Configure Content Filtering Properties. TIME:TimeBasedFeatures The TIME stamp indicates that there was a significant time delay between the time that the message was sent and the time that the message was received. The TIME stamp is used to determine the final SCL rating for the message. The MIME stamp indicates that the e-mail message isn't MIME compliant. The P100 stamp indicates that the message contains a URL that's present in a phishing definition file. The IPOnAllowList stamp indicates that the sender's IP address is on the IP Allow list. For more information about the IP Allow list, see Understanding Connection Filtering. The MessageSecurityAntispamBypass stamp indicates that the message wasn't filtered for content and that the sender has been granted permission to bypass the anti-spam filters. The SenderBypassed stamp indicates that the Content Filter agent doesn't process any content filtering for messages that are received from this sender. For more information, see Configure Content Filtering Properties. The AllRecipientsBypassed stamp indicates that one of the following conditions was met for all recipients listed in the message: The AntispamBypassedEnabled parameter on the recipient's mailbox is set to $true. This is a per-recipient setting that can only be set by an administrator. For more information about this setting, see Set-Mailbox. The message sender is in the recipient's Outlook Safe Senders List. For more information about the Safe Senders List, see Configure Safelist Aggregation. The Content Filter agent doesn't process any content filtering for messages that are sent to this recipient. For more information about recipient exceptions, see Configure Content Filtering Properties.

MIME:MIMECompliance P100:PhishingBlock IPOnAllowList

MessageSecurityAntispamBypass

SenderBypassed

AllRecipientsBypassed

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Anti-Spam Updates

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-07-06 Microsoft Exchange Server 2010 includes many anti-spam features that depend on downloaded data to determine whether a message can be delivered with confidence that it isn't spam. The following data must be kept up-to-date for the anti-spam features to operate optimally:

Content filter updates These updates contain data about phishing Web sites, Microsoft SmartScreen spam heuristics, and other Intelligent Message Filter updates. Content filter updates generally contain about 6 MB of data that's useful for longer periods of time than other anti-spam update data. Microsoft IP Reputation Service data The Microsoft IP Reputation Service is an IP Block list service offered exclusively to Exchange 2010 customers. Administrators can decide to implement and use the Microsoft IP Reputation Service in addition to other real-time block list services. Spam signature data Spam signatures identify the latest spam campaigns. The spam is hashed into a message digest, or spam signature. This data is used by content filtering to assign a higher spam confidence level (SCL) to known spam. The spam signature files are small. A collection of spam signatures is only a few KB. The spam signatures are also time sensitive. Therefore, they're updated more frequently than other anti-spam data sets. Anti-spam updates contain data only. They don't contain updated binaries or libraries. Anti-spam updates don't require mail flow interruption or service restarts.

Updates with Microsoft Update

By default, anti-spam updates aren't automatic. Instead, the administrator must visit Microsoft Update to download and install the content filter updates. The content filter update data is updated and available for download every two weeks. Manual updates from Microsoft Update don't include the Microsoft IP Reputation Service or spam signature data. The Microsoft IP Reputation Service and spam signature data is only available when you use the anti-spam features of Microsoft Forefront Protection 2010 for Exchange Server (FPE).

Updates with Forefront Protection 2010 for Exchange Server

Microsoft Forefront Protection 2010 for Exchange Server (FPE) integrates multiple scan engines into a comprehensive, layered solution that helps you protect your Microsoft Exchange server messaging environment from malware, spam, and inappropriate content. FPE prevents the spread of malicious content by scanning all messages in real time with minimal impact on Exchange server performance or message delivery time. You can enable FPE anti-spam technology in both the Exchange Edge Transport and Exchange Hub Transport roles. However, the Edge Transport role is the preferred location for anti-spam filtering. The technology includes a series of agents that are registered with Exchange and are invoked at specific points in the SMTP pipeline. FPE can also be integrated with Forefront Online Protection for Exchange (FOPE) to provide an additional layer of filtering for your messaging environment. When you deploy FPE, the anti-spam features that are built in to Exchange are disabled. To learn more about how the FPE anti-spam solution works, see Using Antispam Filtering. To learn more about how anti-spam updates work when you're using FPE, see Configuring and scheduling updates.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Attachment Filtering

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-04-28 In Microsoft Exchange Server 2010, you can use attachment filtering to apply filters at the server level to control the attachments that users receive. Attachment filtering is increasingly important in today's environment, where many attachments contain harmful viruses or inappropriate material that may cause significant damage to the user's computer or to the organization as a whole by damaging important documentation or releasing sensitive information to the public. Note: As a best practice, don't remove attachments from digitally signed, encrypted, or rights-protected e-mail messages. If you remove attachments from such messages, you invalidate the digitally signed messages and make encrypted and rights-protected messages unreadable. Looking for management tasks related to anti-spam and antivirus functionality? See Managing Anti-Spam and Antivirus Features.

Types of Attachment Filtering in Exchange 2010

You can use the following types of attachment filtering to control attachments that enter or leave your organization:

Filtering based on file name or file name extension You can filter attachments by specifying the exact file name or file name extension to be filtered. An example of an exact file name filter is BadFilename.exe. An example of a file name extension filter is *.exe. Filtering based on file MIME content type You can also filter attachments by specifying the MIME content type to be filtered. MIME content types indicate what the attachment is, whether it is a JPEG image, an executable file, a Microsoft Office Excel file, or some other file type. E-mail attachments are encoded in email messages as ASCII text. E-mail servers and clients use the information about MIME content type to decode the ASCII text information in an e-mail message and convert it into a usable binary file familiar to the user. Content types are expressed as type/subtype. For example, the JPEG image content type is expressed as image/jpeg. To view a complete list of all file name extensions and content types that attachment filtering can filter on, run the following command.

Get-AttachmentFilterEntry | FL

If an attachment matches one of these filtering criteria, you can configure one of the following actions to be performed on the attachment:

Block whole message and attachment An attachment that matches an attachment filter together with its whole e-mail message can be blocked from entering the messaging system. If an attachment and e-mail message are blocked, the sender receives a delivery status notification (DSN) message that states that the message contains an unacceptable attachment file name. Strip attachment but allow message through An attachment that matches an attachment filter can be removed whereas the e-mail message and any other attachments that don't match the filter are allowed through. If an attachment is stripped, it's replaced with a text file that explains why the attachment was removed. This action is the default setting. Silently delete message and attachment An attachment that matches an attachment filter together with its whole e-mail message can be blocked from entering the messaging system. If an attachment and e-mail message are blocked, neither the sender nor the recipient receives notification. Caution: You can't retrieve e-mail messages and attachments that are blocked or attachments that are stripped. When you configure attachment filters, make sure that you carefully examine all possible file name matches and verify that legitimate attachments won't be affected by the filter. RejectResponse This parameter specifies the string response included in the non-delivery report (NDR) message if an e-mail message that has a filtered e-mail attachment is returned to the sender. For more information, see Configure Attachment Filtering.

File Filtering by Using Forefront Protection for Exchange Server

The file filtering functionality provided by Microsoft Forefront Protection 2010 for Exchange Server includes advanced features that are unavailable in the default Attachment Filter agent included with Exchange 2010 Standard Edition. For example, container files, which are files that contain other files, can be scanned for offending file types. Forefront Protection for Exchange Server filtering can scan the following container files and act upon embedded files:

PKZip (.zip) GNU Zip (.gzip) Self-extracting compressed file archives (.zip) Compressed files (.zip) Java archive (.jar) TNEF (winmail.dat) Structured storage (.doc, .xls, .ppt, and others) MIME (.eml) SMIME (.eml) UUEncode (.uue) UNIX tape archive (.tar) RAR archive (.rar) MACBinary (.bin)

Note: The default Attachment Filter agent included with Exchange 2010 Standard Edition detects file types even if they have been renamed. Attachment filtering also makes sure that compressed files with a .zip or .lzh file name extension don't contain blocked attachments by performing a file name extension match against the files in the compressed files. Forefront Protection for Exchange Server file filtering has the additional capability of determining if a blocked attachment has been renamed within a container file. You can also filter files by file size. Additionally, you can configure Forefront Security for Exchange Server to quarantine filtered files or to send e-mail notifications based on file filter matches. For more information, see Microsoft Forefront Protection 2010 for Exchange Server.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Connection Filtering

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-01-22 The Connection Filter agent is an anti-spam agent enabled on computers running Microsoft Exchange Server 2010 that have the Edge Transport server role installed. The Connection Filter agent relies on the IP address of the remote server that's trying to connect, to determine what action, if any, to take on an inbound message. The remote IP address is available to the Connection Filter agent as a by-product of the underlying TCP/IP connection required for the SMTP session. Because the Connection Filter agent must evaluate the IP address of the remote server that's sending the message to be effective, the Connection Filter agent is typically enabled on the Internet-facing Edge Transport server. However, you may also perform additional configuration to run the Connection Filter agent deeper in the inbound message path. When you configure anti-spam agents on an Edge Transport server, the agents act on messages cumulatively to reduce the number of unsolicited messages that enter the organization. To reduce redundancy and improve overall system performance and efficiency, you must understand the order in which the agents evaluate inbound messages. Understanding the order in which the filters evaluate inbound messages will help you optimize your configuration of the Edge Transport servers. For more information about how to plan and deploy the anti-spam agents, see Understanding Anti-Spam and Antivirus Functionality. When you enable the Connection Filter agent, the Connection Filter agent is the first anti-spam agent to run when an inbound message is evaluated. When an inbound message is submitted to an Edge Transport server on which the Connection Filter agent is enabled, the source IP address of the SMTP connection is checked against IP Allow lists and IP Block lists. If the source IP address is listed on an IP Allow list, the message is sent to the destination without additional processing by other anti-spam agents. If the source IP address is listed on an IP Block list, the SMTP connection is dropped after all RCPT TO headers in the message are processed. Note: The timing of when a specific connection is dropped may depend on other anti-spam configurations. For example, you can specify which recipients always receive email messages, even if the source IP address is blocked. Additionally, you may have configured other agents that rely on content from the DATA command to be parsed. The Connection Filter agent always drops blocked connections according to the overall anti-spam configuration. If the source IP address isn't listed on any IP Allow list or IP Block list, the message continues to flow through other anti-spam agents if other anti-spam agents are configured. Looking for management tasks related to anti-spam and antivirus functionality? See Managing Anti-Spam and Antivirus Features. Contents IP Allow Lists and IP Block Lists Configuring Connection Filtering for Edge Transport Servers That Aren't the First SMTP Entry Point Testing IP Block List and IP Allow List Functionality

IP Allow Lists and IP Block Lists

The Connection Filter agent compares the IP address of the server sending a message to any of the following data stores of IP addresses:

Administrator-defined IP Allow lists and IP Block lists IP Block List providers IP Allow List providers For more information about IP Block List providers, see "IP Block List Providers" later in this topic. You must configure at least one of these data stores of IP addresses for the Connection Filter agent to be operational. If the data stores of IP addresses don't contain the IP addresses on the IP Allow lists or IP Block lists, or if you don't have any IP Block List providers or IP Allow List providers configured, you should disable the Connection Filter agent.

Administrator-Defined IP Allow Lists and IP Block Lists

Administrators of Edge Transport servers maintain administrator-defined lists of IP addresses. You can enter and delete the IP addresses that you want to allow or block by using the Exchange Management Console (EMC) or the Exchange Management Shell. You can add IP addresses individually, by IP address range, or by IP address and subnet mask. When you add an IP address or IP address range, you must specify the IP address or IP address range as an IP Block list address or an IP Allow list address. Additionally, you can specify an expiration time for each IP Block list entry that you create. When you set the expiration time, the expiration time specifies how long the IP Block list entry is active. When the expiration time duration is reached, the IP Block list entry is disabled. By using administrator-defined IP Allow lists and IP Block lists, you can configure connection filtering to support the following scenarios:

To exempt IP addresses from the IP Block lists of IP Block List providers You may have to exempt IP addresses from the IP Block lists of IP Block List providers when legitimate senders are unintentionally put on an IP Block List provider's IP Block list. For example, legitimate senders could be unintentionally put on an IP Block list when an SMTP server was unintentionally configured to act as an open relay. In this scenario, the sender will probably try to correct the misconfiguration and remove the IP address from the IP Block List provider's IP Block list. For more information about IP Block List providers, see "IP Block List Providers" later in this topic.

To deny access from IP addresses that are a source of unsolicited e-mail messages but aren't found on an IP Block List provider's IP Block lists Sometimes, you may receive a large quantity of unsolicited messages from a source that wasn't yet identified by a real-time block list service to which you subscribe.

IP Block List Providers

IP Block List provider services can help you reduce the number of unsolicited e-mail messages that enter your organization. Note: IP Block List provider services are frequently referred to as real-time block list services or RBL services. The EMC refers to real-time block list services as IP Block List provider services. The terms real-time block list services, RBL services, and IP Block List provider services are equivalent. IP Block List provider services compile lists of IP addresses from which spam has originated in the past. Additionally, some IP Block List providers provide lists of IP addresses for which SMTP is configured for open relay. There are also IP Block List provider services that provide lists of IP addresses that support dial-up access. Internet service providers (ISPs) that provide dial-up access services to their clients assign dynamic IP addresses for each dial-up session. Some ISPs block SMTP traffic from dial-up accounts. These ISPs and the attendant dial-up IP ranges aren't typically added to IP Block lists. However, some ISPs allow clients to send SMTP traffic from dial-up accounts. Malicious users take advantage of ISPs that allow SMTP traffic to send spam on dynamically assigned IP addresses. When the IP address is put on an IP Block list, the malicious users start another dial-up session and receive a new IP address. Frequently, a single IP Block List provider can provide a list of IP addresses that covers all these spam threats. You can configure multiple IP Block List provider configurations by using the EMC or the Shell. Each service requires a separate IP Block List provider configuration in the EMC or the Shell. When you configure the Connection Filter agent to use an IP Block List provider, the Connection Filter agent queries the IP Block List provider service to determine whether a match exists with the connecting IP addresses before the message is accepted into the organization. Before the Connection Filter agent contacts the IP Block List provider to verify an IP address, the IP address is first compared to the administrator-defined IP Allow list and IP Block list. If the IP address doesn't exist on either the administrator-defined IP Allow list or IP Block list, the Connection Filter agent queries the IP Block List provider services according to the priority rating assigned to each provider. If the IP address appears on the IP Block list of an IP Block List provider, the Edge Transport server waits for and parses the RCPT TO header, responds to the sending system with an SMTP 550 error, and closes the connection. If the IP address doesn't appear on the IP Block lists of any one of the IP Block List providers, the next agent in the anti-spam chain processes the connection. For more information about the order in which the default anti-spam and antivirus agents filter inbound messages from the Internet, see Understanding Anti-Spam and Antivirus Functionality. When you use the Connection Filter agent, it's a best practice to use one or more IP Block List providers to manage access into your organization. The use of an administrator-defined block list to maintain your own IP Block list is time-consuming and may be impossible from a human resource perspective in most organizations. Therefore, we recommend the use of an external IP Block List provider service, whose sole purpose is to maintain IP Block lists. However, there may be some disadvantages to using an IP Block List provider. Because the Connection Filter agent must query an external entity for each unknown IP address, outages or delays at the IP Block List provider service can cause delays in the processing of messages on the Edge Transport server. In extreme cases, such outages or delays could cause a mail-flow bottleneck on the Edge Transport server. The other disadvantage of using an external IP Block List provider service is that legitimate senders are sometimes added to the IP Block lists of IP Block List providers by mistake. For example, legitimate senders can be added to the IP Block lists maintained by IP Block List providers as the result of an SMTP misconfiguration, where the SMTP server was unintentionally configured to act as an open relay. For each IP Block List provider service that you configure, you can customize the SMTP 550 error returned to the sender when the sender IP address is matched to an IP Block List provider service and is subsequently blocked by the Connection Filter agent. It's a best practice to customize the SMTP 550 error to identify the IP Block List provider service that identifies the sender as a blocked IP address. This best practice enables legitimate senders to contact the IP Block List provider service so that they can be removed from the IP Block List provider service's IP Block list. Different IP Block List provider services may return different codes when the IP address of a remote server sending a message matches an IP address on an IP Block List provider service's IP Block list. Most IP Block List provider services return one of the following data types: bitmask or absolute value. Within these data types, there may be multiple values that indicate the type of list that the submitted IP address is on.

Bitmask Example
This section shows an example of the status codes returned by most Block List providers. For details about the status codes that the provider returns, see the documentation from the specific provider. For bitmask data types, the IP Block List provider service returns a status code of 127.0.0.x, where the integer x is any one of the values listed in the following table.

Values and status codes for bitmask data types

Value 1 2 4 Status code The IP address is on an IP Block list. The SMTP server is configured to act as an open relay. The IP address supports a dial-up IP address.

For absolute value types, the IP Block List provider service returns explicit responses based on the cause of the block of the IP address. The following table shows some examples of absolute values and the explicit responses.

Values and status codes for absolute value data types

Value 127.0.0.2 Explicit response The IP address is a direct spam source.

127.0.0.4 127.0.0.5

The IP address is a bulk mailer. The remote server sending the message is known to support multistage open relays.

IP Allow List Providers

You can also manage inbound messages by using IP Allow List provider services that provide IP Allow lists. IP Allow lists are sometimes referred to as IP safe lists or white lists elsewhere in the software industry. IP Allow List providers maintain lists of IP addresses that are definitively known not to be associated with any spam activity. When an IP Allow List provider returns an IP Allow match, which indicates that the sender's IP address is more likely to be a reputable or safe sender, the Connection Filter agent relays the message to the next agent in the anti-spam chain. Return to top

Configuring Connection Filtering for Edge Transport Servers That Aren't the First SMTP Entry Point
In some organizations, the Edge Transport server role is installed on computers that don't process SMTP requests directly on the Internet. In this scenario, the Edge Transport server is behind another front-end SMTP server that processes inbound messages directly from the Internet. In this scenario, the Connection Filter agent must be able to extract the correct originating IP address from the message. To extract and evaluate the originating IP address, the Connection Filter agent must parse the Received headers from the message and compare those headers to the known SMTP server in the perimeter network. When an RFC-compliant SMTP server receives a message, the server updates the message's Received header with the domain name and IP address of the sender. Therefore, for each SMTP server between the originating sender and the Edge Transport server, the SMTP server adds an additional Received header entry. When you configure your perimeter network to support Exchange 2010, you must specify all the IP addresses for the SMTP servers in your perimeter network. The IP address data is replicated to Edge Transport servers by EdgeSync. When messages are received by the computer that runs the Connection Filter agent, the IP address in the Received header that doesn't match an SMTP server IP address in your perimeter network is assumed to be the originating IP address. You must specify all internal SMTP servers on the transport configuration object in the Active Directory forest before you run connection filtering. Specify the internal SMTP servers by using the InternalSMTPServers parameter on the Set-TransportConfig cmdlet. Return to top

Testing IP Block List and IP Allow List Functionality

After you configure an IP Block List provider service or IP Allow List provider service, you can test to make sure that connection filtering is configured correctly for the particular service. Most IP Block List provider services or IP Allow List provider services provide test IP addresses that you can use to test their services. When you run a test against an IP Block List provider service or an IP Allow List provider service, the Connection Filter agent issues a Domain Name System (DNS) query based on the real-time block list IP address that should respond with a specific response. For more information about how to test IP addresses against an IP Block List provider service or an IP Allow List provider service, see Test-IPAllowListProvider and Test-IPBlockListProvider. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Content Filtering

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-04-28 The Content Filter agent evaluates inbound e-mail messages and assesses the probability that an inbound message is legitimate or spam. Unlike many other filtering technologies, the Content Filter agent uses characteristics from a statistically significant sample of e-mail messages. The inclusion of legitimate messages in this sample reduces the chance of mistakes. Because the Content Filter agent recognizes characteristics of legitimate messages and spam, its accuracy is increased. Updates to the Content Filter agent are available periodically through Microsoft Update. Contents Using the Content Filter Agent Configuring the Content Filter Agent Using SCL Value Stamped by the Content Filter Agent in Edge Transport Rules Forefront Protection 2010 for Exchange Server

Using the Content Filter Agent

The Content Filter agent is one of several anti-spam agents. When you configure anti-spam agents on a computer that has the Edge Transport server role installed, the agents act on messages cumulatively to reduce the amount of spam that enters the organization. For more information about how to plan and deploy anti-spam agents, see Understanding Anti-Spam and Antivirus Functionality. The Content Filter agent assigns a spam confidence level (SCL) rating to each message. The SCL rating is a number between 0 and 9. A higher SCL rating indicates that a message is more likely to be spam. You can configure the Content Filter agent to take the following actions on messages according to their SCL rating:

Delete message Reject message Quarantine message For example, you may determine that messages that have an SCL rating of 7 or higher must be deleted, messages that have an SCL rating of 6 must be rejected, and messages that have an SCL rating of 5 must be quarantined. You can adjust the SCL threshold behavior by assigning different SCL ratings to each of these actions. For more information about how to adjust the SCL threshold to suit your organization's requirements and about per-recipient SCL thresholds, see Understanding Spam Confidence Level Threshold. Note: Messages that are over 11 MB aren't scanned by the Intelligent Message Filter. Instead, they pass through the Content Filter without being scanned. However, the default maximum message size limit configured on Exchange 2010 Receive connectors is 10 MB. Therefore, the 11 MB threshold for the Intelligent Message Filter isn't a practical concern in the default Exchange configuration.

Allow Phrases and Block Phrases

You can customize how the Content Filter agent assigns SCL values by configuring custom words. Custom words are individual words or phrases that the Content Filter agent uses to apply appropriate filter processing. You configure approved words or phrases with Allow phrases and unapproved words or phrases with Block phrases. When the Content Filter agent detects a preconfigured Allow phrase in an inbound message, the Content Filter agent automatically assigns an SCL value of 0 to the message. Alternatively, when the Content Filter agent detects a configured Block phrase in an inbound message, the Content Filter agent assigns an SCL rating of 9. You can enter custom words or phrases in any combination of uppercase and lowercase letters. However, when the Content Filter agent evaluates message content, it ignores case. The maximum number of custom words or phrases that can be created is 800.

Outlook E-mail Postmark Validation

The Content Filter agent also includes Microsoft Office Outlook E-mail Postmark validation, a computational proof that Outlook applies to outgoing messages to help recipient messaging systems distinguish legitimate e-mail from junk e-mail. This feature helps reduce the chance of false positives. In the context of spam filtering, a false positive exists when a spam filter incorrectly identifies a message from a legitimate sender as spam. When Outlook E-mail Postmark validation is enabled, the Content Filter agent parses the inbound message for a computational postmark header. The presence of a valid, solved computational postmark header in the message indicates that the client computer that generated the message solved the computational postmark. Computers don't require significant processing time to solve individual computational postmarks. However, processing postmarks for many messages may be prohibitive to a malicious sender. Anyone who sends millions of spam messages is unlikely to invest the processing power that is required to solve computational postmarks for all outbound spam. If a sender's e-mail contains a valid, solved computational postmark, it's unlikely that the sender is a malicious sender. In this case, the Content Filter agent would lower the SCL rating. If the postmark validation feature is enabled and an inbound message either doesn't contain a computational postmark header or the computational postmark header isn't valid, the Content Filter agent would not change the SCL rating.

Bypassing the Recipient, Sender, and Sender Domain

In some organizations, all e-mail to certain aliases must be accepted. This scenario can introduce problems if your organization is in an industry that manages significant volumes of spam. For example, a company named Woodgrove Bank has an alias named customerloans@woodgrovebank.com that provides e-mail-based support to external loan customers. The Exchange administrators configure the Content Filter agent to set Block phrases that filter out words or phrases that are typically used in spam that is sent by unscrupulous loan agencies. To prevent potentially legitimate messages from being rejected, the administrators set exceptions to content filtering by entering a list of SMTP e-mail recipient addresses in the Content Filter agent configuration. You can also specify senders and sender domains that you do not want the Content Filter agent to block.

Safelist Aggregation
In Exchange 2010, the Content Filter agent on the Edge Transport server uses the Outlook Safe Senders Lists, Blocked Sender List, Safe Recipients Lists, and trusted contacts from Outlook to optimize spam filtering. Safelist aggregation is a set of anti-spam functionality that is shared across Outlook and Exchange 2010. As its name suggests, this functionality collects data from the anti-spam safe lists that Outlook users configure and makes this data available to the anti-spam agents on the Edge Transport server. E-mail messages that Outlook users receive from contacts that those users have added to their Outlook Safe Recipients List, Safe Senders List, or trusted contacts list are identified by the Content Filter agent as safe. The Sender Filter agent also performs per-recipient sender filtering using the Blocked Senders list that users configure. For more information, see Understanding Safelist Aggregation.

Configuring the Content Filter Agent

You configure the Content Filter agent by using the Exchange Management Console or the Exchange Management Shell. Important: Configuration changes that you make to the Content Filter agent by using the Exchange Management Console or the Exchange Management Shell are only made to the local computer that has the Edge Transport server role installed. If you have multiple instances of the Edge Transport server role running in your organization, you must make Content Filter configuration changes to each computer. For more information about how to configure content filtering, see Configure Content Filtering Properties.

Using SCL Value Stamped by the Content Filter Agent in Edge Transport Rules
In Exchange 2010, transport rules that run on Edge Transport servers are applied to messages by the Edge Rule agent on the OnEndOfData SMTP transport event. One of the transport rule conditions available on Edge Transport servers is the with a spam confidence (SCL) rating that is greater than or equal to limit transport rule condition. By using this transport rule condition, you can apply a transport rule action to a message based on the SCL value stamped on the message. The Content Filter agent stamps an SCL value on the message based on an analysis of the message content and is used to determine whether the message is spam. The Content Filter agent also runs on the OnEndOfData SMTP transport event.

Note: Although the Content Filter agent also runs on other events, the SCL value is stamped on the message by the instance of the Content Filter agent registered on the OnEndOfData SMTP transport event. Because both the Edge Rule agent and the Content Filter agent run on the OnEndOfData SMTP transport event, the priority value applied to each transport agent is used to determine which transport agent runs first. By default, the Edge Rule agent runs before the Content Filter agent to reduce the cost of processing messages that may be blocked by the Edge Rule agent. However, because the Edge Rule agent runs before the Content Filter agent and therefore the SCL value has not yet been stamped on the message, you can't use the with a spam confidence (SCL) rating that is greater than or equal to limit transport rule condition in the default configuration. For details about how to configure the Content Filter agent to run before the Edge Rule agent on the OnEndOfData SMTP transport event, see Make the SCL Value Available to Edge Transport Rules. This enables the Content Filter agent to stamp an SCL value on a message that can then be read by the with a spam confidence (SCL) rating that is greater than or equal to limit transport rule condition. For more information about transport agents and transport agent priority, see Understanding Transport Agents. If you configure the Content Filter agent with a higher priority value than the Edge Rule agent, the Edge Transport server may incur additional processing costs because all the messages that are received by the Edge Transport server will be evaluated by the Content Filter agent. This is true even if the message is later rejected by a transport rule that is configured on the Edge Rule agent. Also, you will no longer be able to configure a transport rule on the Edge Transport server to stamp a message that has an SCL value of -1. This value indicates to the Content Filter agent that the message should not be evaluated.

Forefront Protection 2010 for Exchange Server

Microsoft Forefront Protection 2010 for Exchange Server (FPE) integrates multiple scan engines into a comprehensive, layered solution that helps you protect your Microsoft Exchange server messaging environment from malware, spam, and inappropriate content. FPE prevents the spread of malicious content by scanning all messages in real time with minimal impact on Exchange server performance or message delivery time. You can enable FPE anti-spam technology in both the Exchange Edge Transport and Exchange Hub Transport roles. However, the Edge Transport role is the preferred location for anti-spam filtering. The technology includes a series of agents that are registered with Exchange and are invoked at specific points in the SMTP pipeline. FPE can also be integrated with Forefront Online Protection for Exchange (FOPE) to provide an additional layer of filtering for your messaging environment. When you deploy FPE, the anti-spam features that are built in to Exchange are disabled. To learn more about how the FPE anti-spam solution works, see Using Antispam Filtering.

 2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Recipient Filtering

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-11-30 The Recipient Filter agent is an anti-spam agent enabled on computers running Microsoft Exchange Server 2010 that have the Edge Transport server role installed. The Recipient Filter agent relies on the RCPT TO SMTP header to determine what action, if any, to take on an inbound message. When you configure anti-spam agents on an Edge Transport server, the agents act on messages cumulatively to reduce the number of unsolicited messages that enter the organization. For more information about how to plan and deploy anti-spam agents, see Understanding Anti-Spam and Antivirus Functionality. The Recipient Filter agent blocks messages according to the characteristics of the intended recipient in the organization. The Recipient Filter agent can help you prevent the acceptance of messages in the following scenarios:

Nonexistent recipients You can prevent delivery to recipients that aren't in the organization's address book. For example, you may want to stop delivery to frequently misused account names, such as administrator@contoso.com or support@contoso.com. Restricted distribution lists You can prevent delivery of Internet mail to distribution lists that should be used only by internal users. Mailboxes that should never receive messages from the Internet You can prevent delivery of Internet mail to a specific mailbox or alias that's typically used inside the organization, such as Helpdesk. The Recipient Filter agent acts on recipients stored in one or both of the following data sources:

Recipient Block list An administrator-defined list of recipients for which inbound messages from the Internet should never be accepted. Recipient Lookup Verification that the recipient is in the organization. Recipient Lookup requires access to Active Directory information provided by EdgeSync to Active Directory Lightweight Directory Services (AD LDS). For more information about Recipient Block lists and Recipient Lookup functionality, see "Recipient Data Sources" later in this topic. When you enable the Recipient Filter agent, one of the following actions is taken on inbound messages according to the characteristics of the recipients. These recipients are indicated by the RCPT TO header.

If the inbound message contains a recipient that is on the Recipient Block list, the Edge Transport server sends a "550 5.1.1 User unknown" SMTP session error to the sending server. If the inbound message contains a recipient that doesn't match any recipients in Recipient Lookup, the Edge Transport server sends a "550 5.1.1 User unknown" SMTP session error to the sending server. If the recipient isn't on the Recipient Block list and the recipient is in Recipient Lookup, the Edge Transport server sends a "250 2.1.5 Recipient OK" SMTP response to the sending server, and the next anti-spam agent in the chain processes the message. Looking for management tasks related to anti-spam and antivirus functionality? See Managing Anti-Spam and Antivirus Features. Contents Configuring AD LDS for Recipient Lookup Recipient Data Sources Tarpitting Functionality Configuring the Tarpitting Interval Multiple Namespaces

Configuring AD LDS for Recipient Lookup

One of the most effective ways to reduce spam is to validate recipients before accepting inbound messages from the Internet. Therefore, it's a good idea to configure the AD LDS instance that runs on the Edge Transport server to synchronize with Active Directory. By default, AD LDS is installed and configured on the Edge Transport server. However, you must configure AD LDS to communicate with an Active Directory domain-joined global catalog server. Most of the time, you must also configure your firewall to enable specific ports to communicate with AD LDS. For more information, see Understanding Edge Subscriptions. After you configure AD LDS to replicate a Recipient Block list from Active Directory, you must then enable blocking of messages sent to recipients who aren't present in the Exchange organization. You enable message blocking on the Blocked Recipients tab of the Recipient Filtering Properties page in the Exchange Management Console (EMC). You can also enable message blocking by using the Set-RecipientFilterConfig cmdlet in the Exchange Management Shell. For more information, see SetRecipientFilterConfig. Return to top

Recipient Data Sources

As mentioned earlier, the Recipient Filter agent references two data sources when it compares recipients on inbound messages: the Recipient Block list and Recipient Lookup.

Recipient Block List

The Recipient Block list is maintained by the Edge Transport server administrators. The Recipient Block list data is stored in the Edge Transport server instance of AD LDS. You must enter blocked recipients on each Edge Transport server computer.

You can enter the recipients that you want the Recipient Filter agent to block in the EMC on the Blocked Recipients tab of the Recipient Filtering Properties page. You use the Set-RecipientFilterConfig cmdlet in the Shell to enter recipients. For more information about how to configure the Recipient Filter agent, see Configure Recipient Filtering Properties.

Recipient Lookup
One benefit of the Recipient Filter agent is the ability to verify that the recipients on an inbound message are in your organization before Exchange 2010 transmits the message into your organization. The ability to verify recipients in your organization relies on a recipient data source available to the Edge Transport server. Because the Edge Transport server isn't an Active Directory domain-joined computer and could be segregated from the organization by a firewall, you must configure a Recipient Lookup data source for the Edge Transport server to use. The Edge Transport server role uses AD LDS for configuration and data storage. For more information, see Understanding Edge Subscriptions. Return to top

Tarpitting Functionality
Recipient Lookup functionality enables the sending server to determine whether an e-mail address is valid or invalid. As mentioned earlier, when the recipient of an inbound message is a known recipient, the Edge Transport server sends back a "250 2.1.5 Recipient OK" SMTP response to the sending server. This functionality provides an ideal environment for a directory harvest attack. A directory harvest attack is an attempt to collect valid e-mail addresses from a particular organization so that the e-mail addresses can be added to a spam database. Because all spam income relies on trying to make people open e-mail messages, addresses known to be active are a commodity that malicious users, or spammers, pay for. Because the SMTP protocol provides feedback for known senders and unknown senders, a spammer can write an automated program that uses common names or dictionary terms to construct e-mail addresses to a specific domain. The program collects all e-mail addresses that return a "250 2.1.5 Recipient OK" SMTP response and discards all e-mail addresses that return a "550 5.1.1 User unknown" SMTP session error. The spammer can then sell the valid e-mail addresses or use them as recipients for unsolicited messages. To combat directory harvest attacks, Exchange 2010 includes tarpitting functionality. Tarpitting is the practice of artificially delaying server responses for specific SMTP communication patterns that indicate high volumes of spam or other unwelcome messages. The intent of tarpitting is to slow down the communication process for such e-mail traffic so that the cost of sending spam increases for the person or organization sending the spam. Tarpitting makes directory harvest attacks too costly to automate efficiently. If tarpitting isn't configured, Exchange Server immediately returns a "550 5.1.1 User unknown" SMTP session error to the sender when a recipient isn't located in Recipient Lookup. Alternatively, if tarpitting is configured, SMTP waits a specified number of seconds before it returns the "550 5.1.1 User unknown" error. This pause in the SMTP session makes automating a directory harvest attack more difficult and less cost-effective for the spammer. By default, tarpitting is configured for 5 seconds on Receive connectors. To configure the time before SMTP returns the "550 5.1.1 User unknown" error, use the EMC or the Shell to set the TarpitInterval value on the Receive connector. For more information about how to administer and configure Receive connectors, see Understanding Receive Connectors. Return to top

Configuring the Tarpitting Interval

As explained in Understanding Recipient Filtering, you can configure the Receive connectors that process inbound messages from the Internet to slow down the SMTP response. Make sure that you enable tarpitting functionality on the Receive connectors, especially if you have enabled the Recipient Lookup feature of recipient filtering. If you don't enable tarpitting, and you have enabled the Recipient Lookup feature, you are exposing your organization to a directory harvest attack. A directory harvest attack will likely cause more spam. When you specify a tarpitting interval time on a Receive connector, tarpitting is enabled. The default value is 5 seconds. We recommend that you start with a value of 5 (seconds). Use caution if you decide to change this value. An overly long interval could disrupt ordinary mail flow, whereas an overly brief interval may not be as effective in thwarting a directory harvest attack. If you change the tarpitting interval value, do so in small increments. If you are running a version of Exchange Server earlier than Microsoft Exchange Server 2010 Service Pack 2 (SP2), you can set the tarpitting interval on the Security tab of the Receive connector property pages in the EMC, or you can use the Set-ReceiveConnector cmdlet in the Exchange Management Shell. For more information about how to use the EMC to configure the tarpitting interval, see Configure Receive Connector Properties. If you are running Exchange Server 2010 SP2, or a later version, you set the tarpitting interval by using the Set-ReceiveConnector cmdlet in the Exchange Management Shell. Return to top

Multiple Namespaces
Some organizations accept e-mail messages for multiple domains. For example, one organization may accept messages for both the Contoso.com and the Woodgrovebank.com domains. Sometimes organizations are authoritative for all the domains for which they accept messages. In the context of SMTP, the organization is authoritative for a domain if the organization hosts and manages the mailboxes for that domain. This relationship extends to the Edge Transport server. An Edge Transport server may accept messages for multiple domains, but it may not be authoritative for all the domains. For example, an Edge Transport server can be configured to be authoritative for all recipients in the Contoso.com domain, but the Edge Transport server still accepts and forwards messages for the Woodgrovebank.com domain. When you enable the Recipient Filter agent, the Recipient Filter agent performs recipient lookups only for the domains specified as authoritative in the transport server configuration. If an Edge Transport server accepts and forwards messages on behalf of another domain, but the Edge Transport server isn't configured as authoritative, the Recipient Filter agent doesn't perform a recipient lookup. However, if a recipient that's not authoritative is specified in the Recipient Block list, the recipient will still be

blocked. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Safelist Aggregation

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-11-29 In Microsoft Exchange Server 2010, safelist aggregation refers to anti-spam functionality shared across Microsoft Outlook and Exchange. This functionality collects data from the anti-spam Safe Recipients Lists, Safe Senders Lists, Blocked Senders Lists, and contact data that Outlook users configure, and makes this data available to the anti-spam agents on the computer that has the Edge Transport server role installed. Safelist aggregation can help reduce the instances of false-positives in anti-spam filtering performed by the Edge Transport server. When you enable and correctly configure safelist aggregation, the Content Filter agent passes safe e-mail messages to the enterprise mailbox without additional processing. E-mail messages that Outlook users receive from contacts that those users have added to their Outlook Safe Recipients List or Safe Senders List or have trusted are identified by the Content Filter agent as safe. An Outlook contact is a person, inside or outside the user's organization, about whom the user can save several types of information, such as e-mail and street addresses, telephone and fax numbers, and Web page URLs. In Exchange 2010, the safelist aggregation process also replicates a per-recipient Blocked Senders List to the Edge Transport server. This allows the Sender Filtering agent on the Edge Transport server to block incoming messages from those senders. Safelist aggregation can help reduce the instances of false-positives in anti-spam filtering performed by the Edge Transport server. A false-positive is a positive test or filter result in a subject or body of data that doesn't possess the attribute for which the filter or test is being conducted. In the context of spam filtering, a false-positive occurs when a spam filter incorrectly identifies a message from a legitimate sender as spam. For organizations that filter hundreds of thousands of messages from the Internet every day, even a small percentage of false-positives means that users might not receive many messages identified incorrectly as spam, which were quarantined or deleted. Safelist aggregation is likely the most effective way to reduce false-positives. In Office Outlook 2007, users can create Safe Senders Lists. Safe Senders Lists specify a list of domain names and e-mail addresses from which the Outlook user wants to receive messages. By default, e-mail addresses in Outlook Contacts and in the Exchange Server global address list are included in this list. By default, Outlook adds all external contacts to which the user sends mail to the Safe Senders List. Contents Information Stored in the Outlook User's Safelist Collection How Exchange Uses the Safelist Collection Hashing of Safelist Collection Entries Enabling Safelist Aggregation

Information Stored in the Outlook User's Safelist Collection

A safelist collection is the combined data from the user's Safe Senders List, Safe Recipients List, Blocked Senders List, and external contacts. This data is stored in Outlook and in the Exchange mailbox. The following types of information are stored in an Outlook user's safelist collection:

Safe senders and safe recipients The From message header indicates a sender. The To field of the e-mail message indicates a recipient. Safe senders and safe recipients are represented by full SMTP addresses, such as masato@contoso.com. Outlook users can add senders and recipients to their safe lists. Blocked senders Just like safe senders, users can block unwanted senders by adding them to their Blocked Senders Lists. Safe domain The domain is the part of an SMTP address that follows the @ symbol. For example, contoso.com is the domain in the masato@contoso.com address. Outlook users can add sending domains to their safe lists. Important: Exchange provides functionality that allows you to specify whether to include the safe domain data for the anti-spam agents on the Edge Transport server by using the Update-SafeList cmdlet. In most cases, we don't recommend that you include domains because users may include the domains of large Internet service providers (ISP), which could unintentionally provide addresses that may be used or spoofed by spammers. By default, Exchange doesn't include the domains during safelist aggregation. External contacts Two types of external contacts can be included in the safelist aggregation. The first type of external contact includes contacts to whom Outlook users have sent mail. This class of contact is added to the Safe Senders List only if an Outlook user selects the corresponding option in the Junk E-mail settings in Outlook 2007. The second type of external contact includes the users' Outlook contacts. Users can add or import these contacts into Outlook. This class of contact is added to the Safe Senders List only if an Outlook user selects the corresponding option in the Junk E-mail Filter settings in Outlook 2010 or Outlook 2007. Return to top

How Exchange Uses the Safelist Collection

The safelist collection is stored on the user's Mailbox server. A user can have up to 1,024 unique entries in a safelist collection. Exchange 2010 has a mailbox assistant, called the Junk E-mail Options mailbox assistant, which monitors changes to the safelist collection for your mailboxes. It then replicates these changes to Active Directory, where the safelist collection is stored on each user object. When the safelist collection is stored on the user object in Active Directory, the safelist collection is aggregated with the anti-spam functionality of Exchange 2010 and is optimized for minimized storage and replication. The Microsoft Exchange EdgeSync service replicates the safelist collection to the Active Directory Lightweight Directory Services (AD LDS) instance on the Edge Transport server. The Edge Transport servers use the safelist collection data during content filtering. Important:

Although the safe recipient data is stored in Outlook and can be aggregated into the safelist collection on the AD LDS instance on the Edge Transport server, the content filtering functionality doesn't act on safe recipient data. Return to top

Hashing of Safelist Collection Entries

Safelist collection entries are hashed (SHA-256) one way before they are stored as array sets across three user object attributes, msExchSafeSenderHash, msExchSafeRecipientHash, and msExchBlockedSendersHash, as a binary large object. When data is hashed, an output of fixed length is produced, and the output is likely to be unique. For hashing of safelist collection entries, a 4-byte hash is produced. When a message is received from the Internet, Exchange hashes the sender address and compares it to the hashes stored on behalf of the Outlook user to whom the message was sent. If the sender matches the safe senders hash, the message bypasses content filtering. If the sender matches the blocked senders hash, the message is blocked. One-way hashing of safelist collection entries performs the following important functions:

Minimizes storage and replication space Most of the time, hashing reduces the size of the data hashed. Therefore, saving and transmitting a hashed version of a safelist collection entry conserves storage space and replication time. For example, a user who has 200 entries in his or her safelist collection would create about 800 bytes of hashed data stored and replicated in Active Directory. Renders user safelist collections unusable by malicious users Because one-way hash values are impossible to reverse-engineer into the original SMTP address or domain, the safelist collections don't yield usable e-mail addresses for malicious users who might compromise an Edge Transport server. Return to top

Enabling Safelist Aggregation

Safelist aggregation is enabled by default in Exchange 2010. Unlike in Exchange Server 2007, you don't need to manually run the Update-SafeList cmdlet to hash and write the safelist collection data to Active Directory. In Exchange 2010, this is accomplished behind the scenes by the Junk E-mail Options mailbox assistant. You can still manually run safelist aggregation by using the UpdateSafelist cmdlet. The Update-SafeList cmdlet reads the safelist collection from the user's mailbox, hashes each entry, sorts the entries for easy search, and then converts the hash to a binary attribute. Finally, the Update-SafeList cmdlet compares the binary attribute that was created to any value stored on the attribute. If the two values are identical, the Update-SafeList cmdlet doesn't update the user attribute value with the safelist aggregation data. If the two attribute values are different, the Update-SafeList cmdlet updates the safelist aggregation value. To make the safelist aggregation data in Active Directory available to Edge Transport servers in the perimeter network, you must install and configure the Microsoft Exchange EdgeSync service so that the safelist aggregation data is replicated to AD LDS. Return to top

Options available in the msexchangemailboxassistants.exe.config file

To activate the options to include safe domains, or to change the maximum values for the default settings, you must change the msexchangemailboxassistants.exe.config file. Specifically, the following settings and values can be changed in the appsettings section of the msexchangemailboxassistants.exe.config file:

Setting IncludeSafeDomains UpdateInterval TestUpdateInterval MaxSafeSenders MaxSafeRecipients MaxBlockedSenders

Value The value for this setting can be True or False. By default, the value for this setting is 15 minutes. This setting can have a value from 15 minutes through 1 day. TestUpdateInterval is used in test environments. This setting can have a value from 10 seconds through 1 hour. 3*1024 2*1024 By default, the value for this setting is 500. The maximum value is 1000.

For example, the settings in the appsettings section of the msexchangemailboxassistants.exe.config file may be as follows:

<configuration> <runtime> <gcConcurrent enabled="false" /> <generatePublisherEvidence enabled="false" /> </runtime> <appSettings> <add key="IncludeSafeDomains" value="true" /> </appSettings> </configuration>

Return to top

 2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Sender Filtering

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-12-17 The Sender Filter agent is an anti-spam filter that's enabled on computers that have the Microsoft Exchange Server 2010 Edge Transport server role installed. The Sender Filter agent relies on the MAIL FROM: SMTP header to determine what action, if any, to take on an inbound e-mail message. When you configure anti-spam filters on an Edge Transport server, the filters act on messages cumulatively to reduce the number of unsolicited messages that enter the enterprise. For more information about how to plan and deploy the anti-spam features, see Understanding Anti-Spam and Antivirus Functionality. The Sender Filter agent acts on messages from specific senders outside the organization. Administrators of Edge Transport servers maintain a list of senders who are blocked from sending messages to the organization. As an administrator, you can block single senders (kim@contoso.com), whole domains (*.contoso.com), or domains and all subdomains (*.contoso.com). You can also configure what action the Sender Filter agent should take when a message that has a blocked sender is found. You can configure the following actions:

The Sender Filter agent rejects the SMTP request with a "554 5.1.0 Sender Denied" SMTP session error and closes the connection. The Sender Filter agent accepts the message and updates the message to indicate that the message came from a blocked sender. Because the message came from a blocked sender and it's marked as such, the Content Filter agent will use this information when it calculates the spam confidence level (SCL). You can use the Exchange Management Console (EMC) or the Exchange Management Shell to designate blocked senders and to define how the Sender Filter agent should act on messages from blocked senders. For more information about how to configure the Sender Filter agent, see Configure Sender Filtering Properties. Important: The MAIL FROM: SMTP headers can be spoofed. Therefore, you shouldn't rely on the Sender Filter agent only. Use the Sender Filter agent and the Sender ID agent together. The Sender ID agent uses the originating IP address of the sending server to try to verify that the domain in the MAIL FROM: SMTP header matches the domain that's registered. For more information about the Sender ID agent, see Understanding Sender ID. Looking for management tasks related to managing transport servers? See Managing Transport Servers.

Using the Sender Filter Agent to Block Messages

By default, sender filtering is enabled on the computer that has the Edge Transport server role installed for inbound messages that come from the Internet but aren't authenticated. These messages are handled as external messages. You can disable the Sender Filter agent in individual computer configurations by using the EMC or the Shell. For more information, see Enable or Disable Sender Filtering. When you enable the Sender Filter agent on a computer, the Sender Filter agent filters all messages that come through all Receive connectors on that computer. As noted earlier in this topic, only messages that come from external sources are filtered. External sources are defined as non-authenticated sources. These are considered anonymous Internet sources. For more information about how to configure Receive connectors and how message source categories are determined, see Understanding Receive Connectors. As a best practice, you shouldn't filter e-mail messages from trusted partners or from inside your organization. When you run anti-spam filters, there's always a chance that the filters will detect false positives. You should enable anti-spam agents to run only on messages from potentially untrusted and unknown sources. This will reduce the chance that anti-spam filters will mishandle legitimate messages. You can enable and disable the Sender Filter agent to run on messages from any source by using the Shell. For more information, see Set-SenderFilterConfig. You can configure the Sender Filter agent to block inbound messages that don't specify a sender and domain in the MAIL FROM: SMTP header. You can use this feature to prevent non-delivery report (NDR) attacks on the Exchange server. Most legitimate SMTP messages come from SMTP servers that provide a sender and domain in the MAIL FROM: SMTP command.

Specifying the Block Action

After you've specified blocked senders and domains, you must specify how you want the Sender Filter agent to act on messages from blocked senders and domains. We recommend that you reject the messages. When you use the Sender Filter agent on which all blocked e-mail addresses and domains are specified by the Edge Transport server administrator, the chance of false positives is relatively less than when you use other anti-spam agents. For example, the Content Filter agent is an antispam agent that relies on many different variables to determine whether a message is spam. There are only two scenarios in which legitimate messages may be rejected by the Sender Filter agent:

If you mistype an e-mail address or domain name, the wrong sender may be blocked. If a domain name is reregistered to a legitimate company after you add the domain to your Blocked Senders list, you will unintentionally block legitimate messages. In either of these cases, it may still make sense to reject the messages.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Sender ID
Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-01-27 The Sender ID agent is an anti-spam agent that's enabled on computers that have the Microsoft Exchange Server 2010 Edge Transport server role installed. The Sender ID agent relies on the RECEIVED SMTP header and a query to the sending system's DNS service to determine what action, if any, to take on an inbound message. When you configure anti-spam agents on an Edge Transport server, the agents act on messages cumulatively to reduce the number of unsolicited e-mail messages that enter the organization. For more information about how to plan and deploy the anti-spam agents, see Understanding Anti-Spam and Antivirus Functionality. Sender ID is intended to combat the impersonation of a sender and a domain, a practice that's frequently called spoofing. A spoofed mail is an e-mail message that has a sending address that was modified to appear as if it originates from a sender other than the actual sender of the message. Spoofed mails typically contain a From: address that purports to be from a certain organization. In the past, it was relatively easy to spoof the From: address, in both the SMTP session, such as the MAIL FROM: header, and in the RFC 822 message data, such as From: "Masato Kawai" masato@contoso.com, because the headers weren't validated. Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents Using Sender ID to Combat Spoofing Updating Your Organization's Internet-Facing DNS to Support Sender ID Specifying Recipients and Sender Domains to Exclude From Sender ID Filtering

Using Sender ID to Combat Spoofing

In Exchange 2010, Sender ID makes spoofing more difficult. When you enable Sender ID, each message contains a Sender ID status in the metadata of the message. When an e-mail message is received, the Edge Transport server queries the sender's DNS server to verify that the IP address from which the message was received is authorized to send messages for the domain that's specified in the message headers. The IP address of the authorized sending server is referred to as the purported responsible address (PRA). Domain administrators publish sender policy framework (SPF) records on their DNS servers. SPF records identify authorized outbound e-mail servers. If an SPF record is configured on the sender's DNS server, the Edge Transport server parses the SPF record and determines whether the IP address from which the message was received is authorized to send e-mail on behalf of the domain that's specified in the message. For more information about what an SPF record contains and how to create an SPF record, see Sender ID. The Edge Transport server updates the message metadata with the Sender ID status based on the SPF record. After the Edge Transport server updates the message metadata, the Edge Transport server delivers the message as it ordinarily would.

Sender ID Status Values

The Sender ID evaluation process generates a Sender ID status for the message. The Sender ID status is used to evaluate the spam confidence level (SCL) rating for the message. This status can be set to one of the following values:

Pass Both the IP address and Purported Responsible Address (PRA) passed the Sender ID verification check. Neutral Published Sender ID data is explicitly inconclusive. Soft fail The IP address for the PRA may be in the not permitted set. Fail The IP Address is not permitted; no PRA is found in the incoming mail or the sending domain does not exist. None No published SPF data exists in the sender's DNS. TempError A temporary DNS failure occurred, such as an unavailable DNS server. PermError The DNS record is invalid, such as an error in the record format. The Sender ID status is added to the message metadata and is later converted to a MAPI property. The junk e-mail filter in Microsoft Office Outlook uses the MAPI property during the generation of the SCL value. Outlook neither displays the Sender ID status nor necessarily flags a message as junk at certain Sender ID values. Outlook uses the Sender ID status value only during the calculation of the SCL value. Besides the seven scenarios that generate the Sender ID statuses, the Sender ID evaluation process may reveal instances where the From: IP address is missing. If the From: IP address is missing, the Sender ID status can't be set. If the Sender ID status can't be set, Exchange continues to process the message without including a Sender ID status on the message. The message isn't discarded or rejected. In this scenario, Sender ID status isn't set, and an application event is logged. For more information about how the Sender ID status is displayed in messages, see Understanding Anti-Spam Stamps.

Sender ID Options for Handling Spoofed Mail and Unreachable DNS Servers
You can also define how the Edge Transport server handles messages that are identified as spoofed mail and how the Edge Transport server handles messages when a DNS server can't be reached. The options for how the Edge Transport server handles spoofed mail and unreachable DNS servers include the following

actions:

Stamp the status This option is the default action. All inbound messages to your organization have the Sender ID status included in the metadata of the message. Reject This option rejects the message and sends an SMTP error response to the sending server. The SMTP error response is a 5xx level protocol response with text that corresponds to the Sender ID status. Delete This option deletes the message without informing the sending system of the deletion. In fact, the Edge Transport server sends a fake OK SMTP command to the sending server and then deletes the message. Because the sending server assumes the message was sent, it doesn't retry sending the message in the same session. For more information about how to configure the Sender ID agent, see Configure Sender ID Properties. Return to top

Updating Your Organization's Internet-Facing DNS to Support Sender ID

The effectiveness of Sender ID depends on specific DNS data. The more organizations that update their Internet-facing DNS servers by using an SPF record, the more effectively Sender ID identifies spoofed e-mail messages. To support the Sender ID infrastructure, you must update your Internet-facing DNS data by creating an SPF record and hosting the SPF record on your public DNS servers. For more information about how to create and deploy SPF records, see Sender ID. Return to top

Specifying Recipients and Sender Domains to Exclude From Sender ID Filtering

You may want to exclude specific recipients and sender domains from Sender ID filtering. To do this, specify the recipients and sender domains in the Exchange Management Shell. You can't specify the recipients and sender domains in the Exchange Management Console. For more information about how to set recipient and sender domain exclusions for Sender ID, see Set-SenderIdConfig. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Sender Reputation

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-07-07 Sender reputation is anti-spam functionality that's enabled on computers that have the Microsoft Exchange Server 2010 Edge Transport server role installed to block messages according to many characteristics of the sender. Sender reputation relies on persisted data about the sender to determine what action, if any, to take on an inbound message. When you configure anti-spam agents on an Edge Transport server, the agents act on messages cumulatively to reduce the number of unsolicited messages that enter the organization. For more information about how to plan and deploy the anti-spam agents, see Understanding Anti-Spam and Antivirus Functionality. Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents Calculation of the Sender Reputation Level Use of the SRL Enabling and Configuring the Detection of Open Proxy Servers Setting the SRL Block Threshold

Calculation of the Sender Reputation Level

A sender reputation level (SRL) is calculated from the following statistics:

HELO/EHLO analysis The HELO and EHLO SMTP commands are intended to provide the domain name, such as Contoso.com, or IP address of the sending SMTP server to the receiving SMTP server. Malicious users, or spammers, frequently forge the HELO/EHLO statement in various ways. For example, they type an IP address that doesn't match the IP address from which the connection originated. Spammers also put domains that are known to be locally supported at the receiving server in the HELO statement in an attempt to appear as if the domains are in the organization. In other cases, spammers change the domain that's passed in the HELO statement. The typical behavior of a legitimate user may be to use a different, but relatively constant, set of domains in their HELO statements. Therefore, analysis of the HELO/EHLO statement on a per-sender basis may indicate that the sender is likely to be a spammer. For example, a sender that provides many different unique HELO/EHLO statements in a specific time period is more likely to be a spammer. Senders who consistently provide an IP address in the HELO statement that doesn't match the originating IP address as determined by the Connection Filter agent are also more likely to be spammers, as are remote senders who consistently provide a local domain name, which is in the same organization as the Edge Transport server, in the HELO statement. Reverse DNS lookup Sender reputation also verifies that the originating IP address from which the sender transmitted the message matches the registered domain name that the sender submits in the HELO or EHLO SMTP command. Sender reputation performs a reverse DNS query by submitting the originating IP address to DNS. The result that's returned by DNS is the domain name that's registered by using the domain naming authority for that IP address. Sender reputation compares the domain name that's returned by DNS to the domain name that the sender submitted in the HELO/EHLO SMTP command. If the domain names don't match, the sender is likely to be a spammer, and the overall SRL rating for the sender is adjusted upward. The Sender ID agent performs a similar task, but the success of the Sender ID agent relies on legitimate senders to update their DNS infrastructure to identify all the e-mail-sending SMTP servers in their organization. By performing a reverse DNS lookup, you can help identify potential spammers. Analysis of SCL ratings on messages from a particular sender When the Content Filter agent processes a message, it assigns a spam confidence level (SCL) rating to the message. The SCL rating is a number from 0 through 9. A higher SCL rating indicates that a message is more likely to be spam. Data about each sender and the SCL ratings that their messages yield is persisted for analysis by sender reputation. Sender reputation calculates statistics about a sender according to the ratio between all messages from that sender that had a low SCL rating in the past and all messages from that sender that had a high SCL rating in the past. Additionally, the number of messages that have a high SCL rating that the sender has sent in the last day is applied to the overall SRL. Sender open proxy test An open proxy is a proxy server that accepts connection requests from anyone anywhere and forwards the traffic as if it originated from the local hosts. Proxy servers relay TCP traffic through firewall hosts to provide user applications transparent access across the firewall. Because proxy protocols are lightweight and independent of user application protocols, proxies can be used by many different services. Proxies can also be used to share a single Internet connection by multiple hosts. Proxies are usually set up so that only trusted hosts inside the firewall can cross through the proxies. Open proxies can exist because of either of the following conditions: Unintentional misconfiguration. Malicious Trojan horse programs. A Trojan horse program is a program that masquerades as another common program in an attempt to receive information. Frequently with insufficient logging, open proxies provide an ideal way for malicious users to hide their true identities and launch denial of service attacks (DoS) or send spam. As more proxy servers are configured to be open by default, open proxies have become more common. Additionally, malicious users can use multiple open proxies together to hide the sender's originating IP address. When sender reputation performs an open proxy test, it does so by formatting an SMTP request in an attempt to connect back to the Edge Transport server from the open proxy. If an SMTP request is received from the proxy, sender reputation verifies that the proxy is an open proxy and updates the open proxy test statistic for that sender. Sender reputation weighs each of these statistics and calculates an SRL for each sender. The SRL is a number from 0 through 9 that predicts the probability that a specific sender is a spammer or otherwise malicious user. A value of 0 indicates that the sender isn't likely to be a spammer; a value of 9 indicates that the sender is likely to be a spammer. You can configure a block threshold from 0 through 9 at which sender reputation issues a request to the Sender Filter agent, and, therefore, blocks the sender from sending a message into the organization. When a sender is blocked, the sender is added to the Blocked Senders list for a configurable period. How blocked messages are handled depends on the configuration of the Sender Filter agent. The following actions are the options for handling blocked messages:

Reject

Delete and archive Accept and mark as a blocked sender If a sender is included in the IP Block list or Microsoft IP Reputation Service, sender reputation issues an immediate request to the Sender Filter agent to block the sender. To take advantage of this functionality, you must enable and configure the Microsoft Exchange Anti-spam Update Service. By default, the Edge Transport server sets a rating of 0 for senders that haven't been analyzed. After a sender has sent 20 or more messages, sender reputation calculates an SRL that's based on the statistics listed earlier in this topic. Return to top

Use of the SRL

Sender reputation acts on messages during two phases of the SMTP session:

At the MAIL FROM: SMTP command Sender reputation acts on a message only if the message was blocked or otherwise acted on by the Connection Filter agent, Sender Filter agent, Recipient Filter agent, or Sender ID agent. In this case, sender reputation retrieves the sender's current SRL rating from the sender profile that's persisted about that sender in the Edge Transport server database. After this rating is retrieved and evaluated, the Edge Transport server configuration dictates the behavior that occurs at a particular connection according to the block threshold. After the "end of data" SMTP command The end of data transfer (_EOD) SMTP command is given when all the actual message data is sent. At this point in the SMTP session, many of the anti-spam agents have processed the message. As a by-product of anti-spam processing, the statistics that sender reputation relies on are updated. Therefore, sender reputation has the data to calculate or recalculate an SRL rating for the sender. For more information, see Configure Sender Reputation Properties. Return to top

Enabling and Configuring the Detection of Open Proxy Servers

Sender reputation evaluates several sender characteristics to calculate an SRL. Among the characteristics that sender reputation evaluates are the results of a test for open proxy servers. Frequently, spammers route messages through open proxy servers on the Internet. By routing spam through open proxy servers, spammers can send messages that appear to originate from a different server than their own. When sender reputation calculates an SRL, sender reputation tries to connect to the sender's originating IP address by using a variety of common proxy protocols, such as SOCKS4, SOCKS5, HTTP, Telnet, Cisco, and Wingate. Sender reputation formats a protocol-specific request in an attempt to connect back to the Edge Transport server from the open proxy server by using an SMTP request. If an SMTP request is received from the proxy server, sender reputation verifies that the proxy server is an open proxy server and adjusts the SRL rating according to this result. By default, detection of open proxy servers is enabled on sender reputation. For more information about how to enable detection of open proxy servers, see Configure Sender Reputation Properties. For more information about how to configure detection of open proxy servers, see Configure Outbound Access for Detection of Open Proxy Servers for Sender Reputation. Return to top

Setting the SRL Block Threshold

The SRL is a number from 0 through 9 that predicts the probability that a specific sender is a spammer or otherwise malicious user. You must set a threshold for sender blocking by SRL. This SRL block threshold defines the SRL value that must be exceeded for sender reputation to block a sender. By default, the SRL is set at 7. You should monitor the effectiveness of the agent at the default level. You may find that you can adjust the value to meet the needs of your organization. If you set other anti-spam agents aggressively, you may be able to set a higher SRL threshold for sender reputation than you would if the other anti-spam agents weren't set aggressively. For more information about how to adjust anti-spam configurations so that they work together to reduce spam, see Understanding Anti-Spam and Antivirus Functionality. If the SRL block threshold is exceeded for a particular sender, sender reputation adds the sender to the IP Block list on the Connection Filter agent. Sometimes, spammers send batches of spam from a single sender. In this scenario, if sender reputation calculates an SRL that exceeds the SRL block threshold, the sender is added to the Sender Block List for a configurable duration of time. The default duration is 24 hours. After 24 hours, the sender is removed from the Sender Block List and can send messages again. When a sender is added to the IP Block list, sender reputation deletes the profile for the sender. Sender reputation deletes the profile because the blocked sender's existing profile indicates that the sender's SRL exceeds the SRL block threshold. This would cause the blocked sender to be added to the IP Block list again as soon as the duration for sender blocking ends. For more information, see Configure Sender Reputation Properties. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Spam Confidence Level Threshold

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-09-10 In Microsoft Exchange Server 2010, you can define specific actions according to spam confidence level (SCL) thresholds. For example, you can define different thresholds for rejecting, deleting, or quarantining messages on a server that has the Edge Transport server role installed. The combination of this SCL threshold configuration on the Edge Transport server and the SCL Junk E-mail folder configuration on the user mailbox helps you implement a more comprehensive and precise anti-spam strategy. This more precise and detailed SCL threshold adjustment functionality in Exchange 2010 can help you reduce the overall cost of deploying and maintaining an anti-spam solution across your Exchange organization. The SCL threshold configuration is used by the Content Filter agent, one of the default anti-spam agents included with Exchange 2010. The Content Filter agent uses Microsoft SmartScreen technology to assess the contents of a message and to assign an SCL rating to each message. The Content Filter agent performs this function late in the anti-spam cycle, after other anti-spam agents have processed any inbound messages. Many of the other antispam agents that process inbound messages before they're processed by the Content Filter agent are deterministic in how they act on a message. For example, the Connection Filter agent rejects any message sent from an IP address on a real-time block list. The Sender Filter agent and Recipient Filter agent process messages in a similarly deterministic manner. In Exchange 2010, these deterministic anti-spam agents process messages first and therefore greatly reduce the number of messages that must be processed by the Content Filter agent. For more information about the order in which anti-spam agents process messages, see Understanding Anti-Spam and Antivirus Mail Flow. Because content filtering isn't an exact, deterministic process, the ability to adjust the action that the Content Filter agent performs on different SCL values is important. By carefully adjusting the SCL threshold configuration, you can minimize the following:

Size of the spam quarantine storage Number of legitimate e-mail messages mistakenly quarantined Number of legitimate e-mail messages that reach the Microsoft Outlook user's Junk E-mail folder Number of offensive spam e-mail messages that reach the Outlook user's Inbox or Junk E-mail folder Number of spam e-mail messages that reach the Outlook user's Inbox Looking for management tasks related to anti-spam and antivirus functionality? See Managing Anti-Spam and Antivirus Features.

SCL Threshold Actions in Exchange 2010

In Exchange 2010, by adjusting SCL threshold actions, you can escalate the content filtering action taken on messages that have a greater risk of being spam. To understand this functionality, it's helpful to understand the different SCL threshold actions and how they're implemented:

SCL delete threshold When the SCL value for a specific message is equal to or higher than the SCL delete threshold, the Content Filter agent deletes the message. There's no protocol-level communication that tells the sending system or sender that the message was deleted. If the SCL value for a message is lower than the SCL delete threshold value, the Content Filter agent doesn't delete the message. Instead, the Content Filter agent compares the SCL value to the SCL reject threshold. SCL reject threshold When the SCL value for a specific message is equal to or higher than the SCL reject threshold, the Content Filter agent deletes the message and sends a rejection response to the sending system. You can customize the rejection response. In some cases, a non-delivery report (NDR) is sent to the original sender of the message. If the SCL value for a message is lower than the SCL delete and SCL reject threshold values, the Content Filter agent doesn't delete or reject the message. Instead, the Content Filter agent compares the SCL value to the SCL quarantine threshold. SCL quarantine threshold When the SCL value for a specific message is equal to or higher than the SCL quarantine threshold, the Content Filter agent sends the message to a quarantine mailbox. E-mail administrators must periodically review the quarantine mailbox. If the SCL value for a message is lower than the SCL delete, reject, and quarantine threshold values, the Content Filter agent doesn't delete, reject, or quarantine the message. Instead, the Content Filter agent sends the message to the appropriate Mailbox server, where the per-recipient SCL Junk E-mail folder threshold value of the message is evaluated. SCL Junk E-mail folder threshold If the SCL value for a specific message exceeds the SCL Junk E-mail folder threshold, the Mailbox server puts the message in the Outlook user's Junk E-mail folder. If the SCL value for a message is lower than the SCL delete, reject, quarantine, and Junk E-mail folder threshold values, the Mailbox server puts the message in the user's Inbox. For example, if you set the SCL delete threshold to 8, the SCL reject threshold to 7, the SCL quarantine threshold to 6, and the SCL Junk E-mail folder threshold to 5, all email with an SCL of 5 or lower will be delivered to the user's Inbox. As you plan and deploy your strategy for adjusting the SCL threshold, it's important to understand that the Content Filter agent and the SCL Junk E-mail folder process the SCL threshold value differently. The Content Filter agent takes action on the SCL threshold value that you configure. The SCL Junk E-mail folder takes action on the SCL threshold value that you configure plus 1. For example, if you configure the Delete action to an SCL of 4 on the Content Filter agent, all messages with an SCL of 4 or greater are deleted. However, if you configure the Delete action to an SCL of 4 on the SCL Junk E-mail folder, all messages with an SCL of 5 or greater are deleted. To configure the SCL Junk E-mail folder threshold on individual user mailboxes, you must use the Set-Mailbox cmdlet in the Exchange Management Shell. You can configure the SCL delete, reject, and quarantine thresholds in two locations:

On the content filter configuration (per-transport server SCL configuration) We recommend that you set the organization-wide SCL thresholds on the content filter configuration on the Edge Transport server. If you run anti-spam agents on the Hub Transport server, set the organization-wide SCL thresholds on the Hub Transport server. By applying the same SCL thresholds across all transport servers, you can establish a consistent baseline level of SCL functionality across the organization. Over time, as you analyze the spam functionality and metrics provided by the anti-spam logging and reporting features, you can make additional adjustments to these SCL threshold configurations as needed. On user mailboxes (per-recipient SCL configuration) You can use the Set-Mailbox cmdlet to set per-recipient SCL delete, reject, and quarantine thresholds on individual user mailboxes. As mentioned earlier in this topic, you set the SCL Junk E-mail folder threshold on individual user mailboxes by using the SetMailbox cmdlet. The per-recipient SCL delete, reject, and quarantine thresholds are stored in Active Directory and are replicated to the Edge Transport servers by the Microsoft Exchange EdgeSync service. The per-recipient SCL threshold configurations are used by the Content Filter agent even if you've set per-transport server SCL configurations. Therefore, if you've set per-recipient SCL thresholds, the Content Filter agent uses the per-recipient SCL thresholds for specific users instead of the SCL configuration on the Content Filter agent. Note:

Per-recipient SCL thresholds are not enforced on mail received through distribution groups. These types of messages are rejected at the Transport server before the per-recipient threshold settings are applied. Additionally, if you're using Microsoft Forefront Protection 2010 for Exchange Server, any per-recipient SCL threshold settings replicated to the Edge Transport servers by the Microsoft Exchange EdgeSync service will take precedence over the Forefront anti-spam settings. For more information about how to use the Set-Mailbox cmdlet, see Set-Mailbox.

Best Practice for Setting Up and Adjusting SCL Thresholds

We recommend that you set up and adjust the SCL thresholds as follows:

1. Enable the SCL delete, reject, and quarantine thresholds on the content filter configuration on each Edge Transport server. We recommend that you enable SCL thresholds at an organization level and that you use the default values for these SCL thresholds. The default values were set by the Exchange Server team according to real-world data from the Microsoft IT messaging department and from Exchange 2010 early adopter feedback. The default values are optimized for large, global enterprise deployments. If needed, you can also configure the SCL delete, reject, and quarantine thresholds on a per-recipient configuration to bypass the SCL thresholds configured at the organization level. For more information about how to set the SCL thresholds on the content filter configurations, see Configure Content Filtering Properties. 2. Monitor spam reports and logs closely for the first week after you enable the SCL thresholds. You can use several built-in scripts located in the %ExchangeInstallPath%\Scripts folder, such as get-AntispamSCLHistogram.ps1, for gathering filtering result data. If the data indicates that you must make immediate adjustments, reconfigure the SCL thresholds. Otherwise, collect data and analyze the spam reporting to determine whether adjustments are required.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Spam Quarantine

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 Many organizations are bound by legal or regulatory requirements to preserve or deliver all legitimate e-mail messages. In Microsoft Exchange Server 2010, spam quarantine is a feature of the Content Filter agent that reduces the risk of losing legitimate messages. Spam quarantine provides a temporary storage location for messages identified as spam that shouldn't be delivered to a user mailbox inside the organization. Messages identified by the Content Filter agent as spam are wrapped in a non-delivery report (NDR) and delivered to a spam quarantine mailbox inside the organization. You can manage messages delivered to the spam quarantine mailbox and take appropriate actions. For example, you can delete messages or let messages flagged as false positives in anti-spam filtering be routed to their intended recipients. In addition, you can configure the spam quarantine mailbox to automatically delete messages after a designated time period. For more information about how the anti-spam agents filter inbound messages and the order in which the agents are applied, see Understanding Anti-Spam and Antivirus Functionality. Looking for management tasks related to anti-spam and antivirus functionality? See Managing Anti-Spam and Antivirus Features. Contents Spam Confidence Level Spam Quarantine Exchange Hosted Services

Spam Confidence Level

When an external user sends e-mail messages to a server running Exchange that runs the anti-spam features, the anti-spam features cumulatively evaluate characteristics of the messages and act as follows:

Those messages suspected to be spam are filtered out. A rating is assigned to messages based on the probability that a message is spam. This rating is stored with the message as a message property called the spam confidence level (SCL) rating. Spam quarantine uses the SCL rating to determine whether mail has a high probability of being spam. The SCL rating is a numeric value from 0 through 9, where 0 is considered less likely to be spam, and 9 is considered most likely to be spam. You can configure mail that has a certain SCL rating to be deleted, rejected, or quarantined. The rating that triggers any of these actions is referred to as the SCL quarantine threshold. Within content filtering, you can configure the Content Filter agent to base its actions on the SCL quarantine threshold. For example, you can set the following conditions:

SCL delete threshold is set to 8. SCL reject threshold is set to 7. SCL quarantine threshold is set to 6. SCL Junk E-mail folder threshold is set to 5. Based on the preceding SCL thresholds, all e-mail with an SCL of 6 will be delivered to the spam quarantine mailbox. For more information, see Configure Content Filtering Properties. Return to top

Spam Quarantine
When messages are received by the Edge Transport server and all default anti-spam filters are enabled, the anti-spam agents apply their filters. Then the content filter is applied as follows:

If the SCL rating is greater than or equal to the SCL quarantine threshold but less than either the SCL delete threshold or SCL reject threshold, the message goes to the spam quarantine mailbox. If the SCL rating is lower than the spam quarantine threshold, it's delivered to the recipient's Inbox. The message administrator uses Microsoft Office Outlook 2007 to monitor the spam quarantine mailbox for false positives. If a false positive is found, the administrator can send the message to the recipient's mailbox. The message administrator can review the anti-spam stamps if either of the following conditions is true:

Too many false positives are filtered into the spam quarantine mailbox. Not enough spam is being rejected or deleted. For more information, see Understanding Anti-Spam Stamps.

You can then adjust the SCL settings to more accurately filter the spam coming into the organization. For more information, see Understanding Spam Confidence Level Threshold. To use spam quarantine, you must follow these steps:

1. 2. 3. 4. 5. 6.

Enable content filtering. Create a spam quarantine mailbox. Specify the spam quarantine mailbox. Configure the SCL quarantine threshold. Manage the spam quarantine mailbox. Adjust the SCL quarantine threshold as needed.

Enabling Content Filtering

You must enable content filtering before you can apply spam quarantine. By default, the Content Filter agent filters all external messages that come through all Receive connectors on the computer on which the Content Filter feature is enabled. Important: Configuration changes that you make to the Content Filter agent by using the Exchange Management Console or the Exchange Management Shell are made only to the local computer that has the Edge Transport server role installed. If multiple instances of the Edge Transport server role are running in your organization, you must apply sender reputation configuration changes to each computer. For more information, see Enable or Disable Content Filtering.

Creating a Spam Quarantine Mailbox

You must create a spam quarantine mailbox before you can enable the feature. To set up a spam quarantine mailbox, you must follow these steps:

Create a dedicated Exchange database We recommend that you create a dedicated database for the spam quarantine mailbox. The spam quarantine mailbox should have a large database, because if the storage quota limit is reached, messages will be lost. For more information, see Create a Mailbox Database. Create an Active Directory user We recommend that you create a separate Active Directory user for the spam quarantine mailbox. You may apply different recipient policies, such as messaging records management and mailbox size, and delegation rights, according to your organization's compliance policies and needs. Create a user mailbox You must create a mailbox that you can use as the spam quarantine mailbox with an appropriate messaging records management policy that includes mailbox size and the number of days that messages will be saved before they are deleted. For more information, see Messaging Records Management. Note: If a quarantined message is rejected because of a storage quota, the message will be lost. Exchange doesn't generate NDRs for quarantined messages because the quarantined messages are wrapped as NDRs. For more information, see Create a Mailbox. Set up the Outlook account profile You must configure management or delegation of the Outlook account to meet the needs of your organization. In addition, to help with the account management, we recommend that you configure the Outlook profile to expose the original Sender[#0x0069001E], Recipient[#0x0E04001E], and Bcc[#0x0E02001E] fields in the Message view. For more information, see Release Quarantined Messages from the Spam Quarantine Mailbox.

Specifying the Spam Quarantine Mailbox

After you set up the spam quarantine mailbox, you must specify the spam quarantine mailbox in the content filter configuration. You use the Set-ContentFilterConfig cmdlet in the Shell to specify a spam quarantine mailbox. The QuarantineMailbox parameter uses the SMTP address of the spam quarantine mailbox. Important: You must specify the spam quarantine mailbox on all servers that have the Edge Transport server role installed in Active Directory where user mailboxes are located. To specify the spam quarantine mailbox in Active Directory, run the Set-ContentFilterConfig cmdlet on a Hub Transport server. You don't have to have content filtering enabled on the Hub Transport server to specify a spam quarantine mailbox in Active Directory. For more information, see Specify a Spam Quarantine Mailbox.

Configuring the SCL Quarantine Threshold

The SCL quarantine threshold is the value at which a particular message identified as potential spam is delivered to the spam quarantine mailbox. You can set the SCL quarantine threshold to a value from 0 through 9, where 0 is considered less likely to be spam, and 9 is considered most likely to be spam. For more information about how to adjust SCL thresholds to suit your organization's requirements and how to adjust per-recipient SCL thresholds, see Configure Content Filtering Properties.

Managing the Spam Quarantine Mailbox

When you manage your spam quarantine mailbox, follow these guidelines:

Release items that have been sent to the spam quarantine mailbox by using the Send Again feature in Outlook to resend the original message.

For more information, see Release Quarantined Messages from the Spam Quarantine Mailbox. Monitor the spam quarantine mailbox so that the size of the spam quarantine mailbox remains in an acceptable range. The volume of e-mail messages can change because of a larger set of recipients, the natural trend of larger messages, or the threshold on the SCL quarantine action. Monitor the spam quarantine mailbox for false positives. If your spam quarantine mailbox includes many false positives, adjust your SCL quarantine threshold as described in "Adjusting the SCL Quarantine Threshold" later in this topic. For more information about how to determine why false positives are being delivered to the spam quarantine mailbox, see Understanding Anti-Spam Stamps. Use the same Outlook profile to recover quarantined messages from the spam quarantine mailbox. Applying permissions to a different Outlook profile to recover messages isn't supported. You can't use a different Outlook profile to recover or release messages from the spam quarantine mailbox. Important: NDRs identified as spam are deleted, even if their SCL rating indicates that they should be quarantined. NDRs aren't delivered to the spam quarantine mailbox. To track such messages, use the agent log or the message tracking log. For more information, see Get-AgentLog and Search Message Tracking Logs.

Adjusting the SCL Quarantine Threshold

After you configure the SCL quarantine threshold, periodically monitor the settings and adjust them based on your organization's needs. For example, if too many false positives are filtered into the spam quarantine mailbox, raise the SCL quarantine threshold to a larger number. For more information about how to adjust the SCL quarantine threshold, see Understanding Spam Confidence Level Threshold. Return to top

Exchange Hosted Services

Spam filtering and quarantine functionality are enhanced by services available from Microsoft Exchange Hosted Services. Exchange Hosted Services is a set of four distinct hosted services:

Hosted Filtering, which helps organizations protect themselves from e-mail-borne malware Hosted Archive, which helps them satisfy retention requirements for compliance Hosted Encryption, which helps them encrypt data to preserve confidentiality Hosted Continuity, which helps them preserve access to e-mail during and after emergency situations These services integrate with any on-premises Exchange servers that are managed in-house or Hosted Exchange e-mail services that are offered through service providers. For more information about Exchange Hosted Services, see Microsoft Exchange Hosted Services. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Using Edge Transport Rules to Manage Viruses

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 You can use the Edge Rules agent and transport rules in Microsoft Exchange Server 2010 to help protect your organization from viruses. New viruses threaten organizations every day. To minimize the damage caused by viruses, antivirus vendors and administrators must respond to virus threats as soon as possible. Despite a quick response, there will be a gap between the time that a virus threat appears and the time that a solution becomes available. This gap, when a virus threat remains unknown and unresolved, is called a zero-day virus threat. At the same time, viruses that have been circulating on the Internet for many years also continue to pose a significant threat to organizations. Although the majority of these viruses can be identified by antivirus scanners, antivirus scanners may be taken offline by mistake, updated with out-of-date definitions, or experience other problems that make them unavailable. The transport rules that run on computers that have the Edge Transport server role installed are designed to help you manage and control zero-day virus threats and preexisting or ongoing virus threats. For more information about transport rules, see the following topics:

Overview of Transport Rules Understanding How Transport Rules Are Applied Looking for management tasks related to anti-spam and antivirus functionality? See Managing Anti-Spam and Antivirus Features.

Managing Virus Threats

Most viruses contain unique characteristics that identify them as a virus, such as a specific e-mail address in the From message header field, a specific subject, or an attachment. You can configure transport rules to identify potentially harmful messages by these unique characteristics and perform a specific action on them. Available actions include sending the message to a quarantine mailbox, deleting it completely, or adding a warning to the subject.

Identifying Virus Threats

It's important to maximize the number of infected messages that you identify in your perimeter network on Edge Transport servers to reduce the cost of processing the messages after they have entered the Exchange organization. If you can identify an infected message on Edge Transport servers and either reject or delete it, you don't incur the cost of storing the message on your internal servers or the cost of scanning the message for viruses. When you create a transport rule to identify virus threats, you should examine the reports published about the virus and look for unique characteristics that identify the virus and that could be used in a transport rule. The following list describes some unique characteristics that a virus may contain:

Limited number of strings in the subject or message body Specific e-mail address in either the From header field or To header field Specific message header field that has a specific value Important: Although you may be able to identify unique characteristics about a particular virus, you must make sure that these characteristics don't match any content that may exist in legitimate messages. For more information about the types of message content that can be examined by transport rules on an Edge Transport server, see Transport Rule Predicates.

Controlling Virus Threats with Transport Rules

After you have identified the unique characteristics of a virus, you can create a transport rule to perform actions on it. The actions that you perform on specific messages depend on your organization's policies.

Caution: If you decide to drop an SMTP connection, delete a message, or reject a message, you can't retrieve it. If you want to prevent the message from being delivered, but don't want to delete it, configure the rule to deliver the message to a quarantine mailbox. For more information about the actions available on transport rules on an Edge Transport server, see Transport Rule Actions. For more information about how to manage and configure transport rules used to identify and perform actions on messages that may be infected with viruses, see the following topics:

Create a Transport Rule View a Transport Rule Modify a Transport Rule Remove a Transport Rule Configure a Disclaimer The following topics provide additional information that will help you manage and enhance transport rules:

Transport Rule Predicates Transport Rule Actions Regular Expressions in Transport Rules

Using Exchange Hosted Services

Transport messaging policies are enhanced by services available from Microsoft Exchange Hosted Services. Exchange Hosted Services is a set of four distinct hosted services:

Hosted Filtering, which helps organizations protect themselves from e-mail-borne malware Hosted Archive, which helps them satisfy retention requirements for compliance Hosted Encryption, which helps them encrypt data to preserve confidentiality Hosted Continuity, which helps them preserve access to e-mail during and after emergency situations These services integrate with any on-premises Exchange servers that are managed in-house or Hosted Exchange e-mail services that are offered through service providers. For more information about Exchange Hosted Services, see Microsoft Exchange Hosted Services.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Approval Framework

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-11-18

Approval Framework
Microsoft Exchange uses the approval framework for simple decision-making about e-mail messages. For each workflow, the approval framework uses a special mailbox called the arbitration mailbox, which is used to store the original message and the decision state during the approval process. The following workflow is followed by any application that uses the approval framework:

1. 2. 3. 4. 5. 6.

The user starts a new workflow process using the workflow application. The workflow application sends an initiation message to the arbitration mailbox. Exchange stores the message in the arbitration mailbox and sends approval requests to the specified decision makers. The specified decision makers either approve or reject the approval request. Exchange marks the decision on the original message that is stored in the arbitration mailbox. The workflow application monitors the arbitration mailbox and acts on the decisions that are marked on the original message.

In Exchange Server 2010, the approval framework is used for the following:

Moderated recipients For more information, see Understanding Moderated Transport. Joining and departing distribution groups For more information, see step 7 in Configure Distribution Group Properties.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Back Pressure

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-02-02 Back pressure is a system resource monitoring feature of the Microsoft Exchange Transport service that exists on Microsoft Exchange Server 2010 Hub Transport and Edge Transport servers. Exchange transport can detect when vital resources, such as available hard disk space and memory, are under pressure, and take action in an attempt to prevent service unavailability. Back pressure prevents the system resources from being completely overwhelmed, and Exchange tries to deliver the existing messages. When utilization of the system resource returns to a normal level, the Exchange server gradually resumes normal operation. In Exchange Server 2007, when a Hub Transport or Edge Transport server is under resource pressure, it rejects incoming connections. In Exchange 2010, incoming connections are accepted, but incoming messages over those connections are either accepted at a slower rate or are rejected. When an SMTP host attempts to make a connection to a Hub Transport or Edge Transport server that's in back pressure, the connection will succeed but when the host issues the MAIL FROM command to submit a message, depending on the resource that's under pressure, Exchange either delays the acknowledgement to the MAIL FROM command or rejects it. Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents Resources Monitored Actions Taken by Exchange Transport When Under Resource Pressure Back Pressure Configuration Options in the EdgeTransport.exe.config File Back Pressure Logging Information

Resources Monitored

The following system resources are monitored as part of the back pressure feature:

Free space on the hard disk that stores the message queue database. Free space on the hard disk that stores the message queue database transaction logs. The number of uncommitted message queue database transactions that exist in memory. The memory that's used by the EdgeTransport.exe process. The memory that's used by all other processes. For each monitored system resource on a Hub Transport server or Edge Transport server, the following three levels of resource utilization are applied:

Normal The resource isn't overused. The server accepts new connections and messages. Medium The resource is slightly overused. Back pressure is applied to the server in a limited manner. Mail from senders in the authoritative domain can flow. However, depending on the specific resource under pressure, the server uses tarpitting to delay server response or rejects incoming MAIL FROM commands from other sources. High The resource is severely overused. Full back pressure is applied. All message flow stops, and the server rejects all new incoming MAIL FROM commands. The following sections explain how Exchange handles the situation when a specific resource is under pressure.

Free Hard Disk Space for the Message Queue Database

By default, the message queue database is stored at C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\data\Queue. Exchange monitors the hard disk space utilization for this location. The high level of hard disk space utilization is calculated by using the following formula: 100 * (hard disk size - fixed constant) / hard disk size The value of fixed constant is 500 megabytes (MB). The results of this formula are expressed as a percentage of the total hard disk space that's being used. The results of the formula are always rounded down to the nearest integer. By default, the medium level of hard disk utilization is 2 percent less than the high level. By default, the normal level of hard disk utilization is 4 percent less than the high level. For more information about the message queue database, see Understanding Transport Queues.

Free Hard Disk Space for the Message Queue Database Transaction Logs
By default, the message queue database transaction logs are stored at C:\Program Files\Microsoft\ExchangeServer\V14\TransportRoles\data\Queue. Exchange monitors the hard disk space utilization for this location. The EdgeTransport.exe.config file contains a DatabaseCheckPointDepthMax parameter that has a default value of 512 MB. This parameter controls the total allowed size of all uncommitted transaction logs that exist on the hard disk. This parameter is used in the formula that calculates hard disk utilization.

Note: The value of the DatabaseCheckPointDepthMax parameter applies to all transport-related Extensible Storage Engine (ESE) databases that exist on the Hub Transport server or Edge Transport server. This would include the message queue database and the IP filter database. By default, the high level of hard disk utilization is calculated by using the following formula: 100 * (hard disk size - Max(5 GB, 3*DatabaseCheckPointDepthMax)) / hard disk size The results of the formula are always rounded down to the nearest integer. By default, the medium level of hard disk utilization is 2 percent less than the high level. The normal level of hard disk utilization is 4 percent less than the high level. For more information about the message queue database, see Understanding Transport Queues.

Number of Uncommitted Message Queue Database Transactions in Memory

A list of changes that are made to the message queue database is kept in memory until those changes can be committed to a transaction log. Then the list is committed to the message queue database itself. These outstanding message queue database transactions that are kept in memory are known as version buckets. The number of version buckets may increase to unacceptably high levels because of an unexpectedly high volume of incoming messages, spam attacks, problems with the message queue database integrity, or hard disk performance. When Exchange starts receiving messages, these messages are grouped together in batches and then prepared as version buckets. If an incoming message has a large attachment, it can be separated into multiple batches. These batches that are being processed are known as batch points. The number of outstanding batch points can exceed the set thresholds, especially when there's an unexpectedly high volume of incoming messages with large attachments. When version buckets or batch points are under pressure, the Exchange 2010 transport server will start throttling incoming connections by delaying acknowledgement to incoming messages. Exchange will reduce the rate of inbound message flow by tarpitting, which introduces a delay to the MAIL FROM commands. If the resource pressure condition continues, Exchange will gradually increase the tarpitting delay. After the resource utilization returns to normal, Exchange will gradually start reducing the acknowledgement delay and ease into normal operation. By default, Exchange will start delaying message acknowledgements 10 seconds when under resource pressure. If the resources continue to be under pressure, the delay is increased in 5-second increments up to 55 seconds. Exchange 2010 keeps a history of version bucket and batch point resource utilization. If the resource utilization doesn't go down to normal level for a specific number of polling intervals, known as the history depth, Exchange will stop the tarpitting delay and start rejecting incoming messages until the resource utilization goes back to normal. By default, the history depths for version buckets and batch points are in 10 and 300 polling intervals respectively.

Memory Used by the EdgeTransport.exe Process

By default, the high level of memory utilization by the EdgeTransport.exe process is calculated by using the following formula: 75 percent of the total physical memory or 1 terabyte, whichever is less This calculation doesn't include virtual memory that's available on the hard disk in the paging file, or the memory that's used by other processes. The results of this formula are expressed as a percentage of the total memory that's used by the EdgeTransport.exe process. The results of the formula are always rounded down to the nearest integer. By default, the medium level of memory utilization by the EdgeTransport.exe file is calculated as 73 percent of the total physical memory or 2 percent less than the value of the high level, whichever is less. By default, the normal level of memory utilization by the EdgeTransport.exe file is calculated as 71 percent of the total physical memory or 4 percent less than the value of the high level, whichever is less. If the memory utilization of the EdgeTransport.exe process is higher than the specified normal level, garbage collection is forced. Garbage collection is a process that checks for unused objects that exist in memory, and reclaims the memory that's used by those unused objects. Exchange 2010 keeps a history of the memory utilization of the EdgeTransport.exe process. If the utilization doesn't go down to normal level for a specific number of polling intervals, known as the history depth, Exchange will start rejecting incoming messages until the resource utilization goes back to normal. By default, the history depth for EdgeTransport.exe memory utilization is 30 polling intervals.

Memory Used by All Processes

By default, the high level of memory utilization by all processes is 94 percent of total physical memory. This value doesn't include virtual memory that's available on the hard disk in the paging file. When the specified memory utilization level is reached, message dehydration occurs. Message dehydration is the act of removing unnecessary elements of queued messages that are cached in memory. Complete messages are cached in memory for enhanced performance. Removal of the MIME content of queued messages from memory reduces the memory that's used at the expense of higher latency because the messages are read directly from the message queue database. By default, message dehydration is enabled. Return to top

Actions Taken by Exchange Transport When Under Resource Pressure

The following table summarizes the actions taken by Exchange transport when a specific resource is under pressure.

Back pressure actions taken by Hub Transport and Edge Transport servers when responding to resource pressure
Resource under pressure Utilization level Actions taken

Hard disk space for message queue database

Medium

Reject incoming messages from non-Exchange servers Reject message submissions from Pickup and Replay directories

Hard disk space for message queue database

High

Reject incoming messages from other Exchange servers Reject message submissions from the store driver on Mailbox servers (Hub Transport server only) Reject incoming messages from non-Exchange servers Reject message submissions from Pickup and Replay directories

Hard disk space for message queue database transaction logs

Medium

Reject incoming messages from non-Exchange servers Reject message submissions from Pickup and Replay directories

Hard disk space for message queue database transaction logs

High

Reject incoming messages from other Exchange servers Reject message submissions from the store driver on Mailbox servers (Hub Transport server only) Reject incoming messages from non-Exchange servers Reject message submissions from Pickup and Replay directories

Version buckets

Medium

Introduce or increment the tarpitting delay to incoming messages. If normal level isn't reached for the entire version bucket history depth, take the following actions: Reject incoming messages from non-Exchange servers Reject message submissions from Pickup and Replay directories

Version buckets

High

Introduce or increment the tarpitting delay to incoming messages. If normal level isn't reached for the entire version bucket history depth, take the following actions: Reject incoming messages from other Exchange servers Reject message submissions from the store driver on Mailbox servers (Hub Transport server only) Reject incoming messages from non-Exchange servers Reject message submissions from Pickup and Replay directories

Batch point

Medium

Introduce or increment the tarpitting delay to incoming messages. If normal level isn't reached for the entire batch point history depth, take the following actions: Reject incoming messages from non-Exchange servers Reject message submissions from Pickup and Replay directories

Batch point

High

Introduce or increment the tarpitting delay to incoming messages. If normal level isn't reached for the entire batch point history depth, take the following actions: Reject incoming messages from other Exchange servers Reject message submissions from the store driver on Mailbox servers (Hub Transport server only) Reject incoming messages from non-Exchange servers Reject message submissions from Pickup and Replay directories

Memory used by EdgeTransport.exe process

Medium

Reject incoming messages from non-Exchange servers Reject message submissions from Pickup and Replay directories Force garbage collection

Memory used by EdgeTransport.exe process

High

Reject incoming messages from other Exchange servers Reject message submissions from the store driver on Mailbox servers (Hub Transport server only) Reject incoming messages from non-Exchange servers Reject message submissions from Pickup and Replay directories

Memory used by all processes

Medium

Reject incoming messages from non-Exchange servers Reject message submissions from Pickup and Replay directories Force garbage collection

Memory used by all processes

High

Reject incoming messages from other Exchange servers Reject message submissions from the store driver on Mailbox servers (Hub Transport server only) Reject incoming messages from non-Exchange servers Reject message submissions from Pickup and Replay directories Flush enhanced Domain Name System (DNS) cache from memory Start message dehydration

Return to top

Back Pressure Configuration Options in the EdgeTransport.exe.config File

All configuration options for back pressure are available in the EdgeTransport.exe.config application configuration file. For more information about the EdgeTransport.exe.config file, see Understanding the EdgeTransport.exe.Config File.

Caution: These settings are listed as a reference only. We strongly discourage any modifications to the back pressure settings in the EdgeTransport.exe.config file. Modifications to the back pressure settings may result in poor performance or data loss. We recommend that you investigate and correct the root cause of any back pressure events that you may encounter.

Back pressure configuration options

Parameter name EnableResourceMonitoring ResourceMonitoringInterval PercentageDatabaseDiskSpaceUsedHighThreshold PercentageDatabaseDiskSpaceUsedMediumThreshold Default value TRUE 00:00:02 0. This value indicates that the default formula will be used. 0. This value indicates that the actual value is 2 percent less than the value of PercentageDatabaseDiskSpaceUsedHighThreshold. 0. This value indicates that the actual value is 2 percent less than the value of PercentageDatabaseDiskSpaceUsedMediumThreshold. 0. This value indicates that the default formula will be used. 0. This value indicates that the actual value is 2 percent less than the value of PercentageDatabaseLoggingDiskSpaceUsedHighThreshold. 0. This value indicates that the actual value is 2 percent less than the value of PercentageDatabaseLoggingDiskSpaceUsedMediumThreshold. 0. This value indicates that the default calculation will be used. 0. This value indicates that the actual value is 2 percent less than the value of PercentagePrivateBytesUsedHighThreshold. 0. This value indicates that the actual value is 2 percent less than the value of PercentagePrivateBytesUsedMediumThreshold. 200 120 80 10 4000 2000 1000 300 TRUE 40 00:00:00.100 00:05:00 00:00:00 00:00:55 00:00:05 00:00:10 94

PercentageDatabaseDiskSpaceUsedNormalThreshold

PercentageDatabaseLoggingDiskSpaceUsedHighThreshold PercentageDatabaseLoggingDiskSpaceUsedMediumThreshold

PercentageDatabaseLoggingDiskSpaceUsedNormalThreshold

PercentagePrivateBytesUsedHighThreshold PercentagePrivateBytesUsedMediumThreshold

PercentagePrivateBytesUsedNormalThreshold

VersionBucketsHighThreshold VersionBucketsMediumThreshold VersionBucketsNormalThreshold VersionBucketsHistoryDepth BatchPointHighThreshold BatchPointMediumThreshold BatchPointNormalThreshold BatchPointHistoryDepth BatchPointUseCostForPressure BatchPointBatchSize BatchPointBatchTimeout BatchPointItemExpiryInterval SMTPBaseThrottlingDelayInterval SMTPMaxThrottlingDelayInterval SMTPStepThrottlingDelayInterval SMTPStartThrottlingDelayInterval PercentagePhysicalMemoryUsedLimit

DehydrateMessagesUnderMemoryPressure PrivateBytesHistoryDepth Return to top

TRUE 30

Back Pressure Logging Information

The following list describes the event log entries that are generated by specific back pressure events in Exchange 2010:

Event log entry for an increase in any resource utilization level Event Type: Error Event Source: MSExchangeTransport Event Category: Resource Manager Event ID: 15004 Description: Resource pressure increased from Previous Utilization Level to Current Utilization Level. Event log entry for a decrease in any resource utilization level Event Type: Information Event Source: MSExchangeTransport Event Category: Resource Manager Event ID: 15005 Description: Resource pressure decreased from Previous Utilization Level to Current Utilization Level. Event log entry for critically low available disk space Event Type: Error Event Source: MSExchangeTransport Event Category: Resource Manager Event ID: 15006 Description: The Microsoft Exchange Transport service is rejecting messages because available disk space is below the configured threshold. Administrative action may be required to free disk space for the service to continue operations. Event log entry for critically low available memory Event Type: Error Event Source: MSExchangeTransport Event Category: Resource Manager Event ID: 15007 Description: The Microsoft Exchange Transport service is rejecting message submissions because the service continues to consume more memory than the configured threshold. This may require that this service be restarted to continue normal operation. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Content Conversion

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-11-07 Content conversion is the process of correctly formatting a message for each recipient. The decision to perform content conversion on a message depends on the destination and format of the message being processed. Messages sent to recipients inside the Microsoft Exchange Server organization don't require any content conversion. Only messages sent to external recipients may require content conversion. In an Exchange Server 2010 organization, content conversion is handled by the categorizer on a server that has the Hub Transport server role installed. Categorization on each message happens after a newly arrived message is put in the Submission queue. In addition to recipient resolution and routing resolution, content conversion is performed on the message before the message is put in a delivery queue. If a single message contains multiple recipients, content conversion determines the appropriate encoding for each message recipient. On an Edge Transport server, an abbreviated categorization occurs, which doesn't involve content conversion. Contents Understanding the Structure of E-mail Messages Exchange 2010 and Outlook Message Formats Elements of Content Conversion Content Conversion Performed by the Store Driver Looking for management tasks related to content conversion? See Managing Transport Servers.

Understanding the Structure of E-mail Messages

To better understand content conversion, you must understand the structure of e-mail messages. An SMTP message is based on plain 7-bit US-ASCII text to compose and send e-mail messages. A standard SMTP message consists of the following elements:

Message envelope The message envelope is defined in RFC 2821. The message envelope contains information required to transmit and deliver the message. Recipients never see the message envelope, because it's generated by the message transmission process and isn't actually part of the message contents. Message contents The message contents are defined in RFC 2822. The message contents consist of the following elements: Message header The message header is a collection of header fields. Header fields consist of a field name, followed by a colon (:) character, followed by a field body, and ended by a carriage return/line feed (CR/LF) character combination. A field name must be composed of printable US-ASCII text characters except the colon (:) character. Specifically, ASCII characters that have values from 33 through 57 and 59 through 126 are permitted. A field body may be composed of any US-ASCII characters, except for the carriage return (CR) character and the line feed (LF) character. However, a field body may contain the CR/LF character combination when used in header folding. Header folding is the separation of a single header field body into multiple lines as described in section 2.2.3 of RFC 2822. Other field body syntax requirements are described in sections 3 and 4 of RFC 2822. Message body The message body is a collection of lines of US-ASCII text characters that appears after the message header. The message header and the message body are separated by a blank line that ends with the CR/LF character combination. The message body is optional. Any line of text in the message body must be less than 998 characters. The CR and LF characters can only appear together to indicate the end of a line. When SMTP messages contain elements that aren't plain US-ASCII text, the message must be encoded to preserve those elements. The MIME standard defines a method of encoding content in messages that isn't text. MIME allows for text in other character sets, attachments without text, multipart message bodies, and header fields in other character sets. MIME is defined in RFC 2045, RFC 2046, RFC 2047, RFC 2048, and RFC 2077. MIME defines a collection of header fields that specifies additional message attributes. The following table describes some important MIME header fields.

Important MIME header fields

Header field name MIMEVersion Default value Description

1.0

This header field is the first MIME header field that appears in a MIME-formatted message. This header field appears after the other standard RFC 2822 header fields, but before any other MIME header fields. MIME-aware e-mail clients use this header field to identify a MIME-encoded message. When this header field is absent, MIME-aware e-mail clients identify the message as plain text. This header field identifies the media type of the message content as described in RFC 2046. A media type consists of a type, a subtype, and one or more optional parameters, such as a charset= parameter that defines the MIME character encoding. Types that begin with "x" aren't standard. Subtypes that begin with "vnd." are vendor-specific. The Internet Assigned Numbers Authority (IANA) maintains a list of registered media types. For more information, see MIME Media Types. The multipart media type allows for multiple message parts in the same message by using sections defined by different media types. Some Content-Type field values include text/plain, text/html, multipart/mixed, and multipart/alternative. This header field can describe the following information about a message: The encoding algorithm used to transform any non-US-ASCII text or binary data that exists in the message body. An indicator that describes the current condition of the message body. There can be multiple values of the Content-Transfer-Encoding header field in a MIME message. When the Content-Transfer-Encoding header field appears in the message header, it applies to the whole body of the message. When the Content-Transfer-Encoding header field appears in one of the parts of a multipart message, it applies only to that part of the message. When an encoding algorithm is applied to the message body data, the message body data is transformed into plain US-ASCII text. This transformation allows the message to travel through older SMTP messaging servers that only support messages in US-ASCII text. The values of the Content-Transfer-Encoding header field that indicate an encoding algorithm was used on the message body are as follows:

ContentType

text/plain

ContentTransferEncoding

7bit

Quoted-printable This encoding algorithm uses printable US-ASCII characters to encode the message body data. If the original message text is mostly US-ASCII text, Quoted-printable encoding gives somewhat readable and compact results. All printable USASCII text characters except the equal sign (=) character can be represented without encoding. Base64 This encoding algorithm is based primarily on the privacy-enhanced mail (PEM) standard defined in RFC 1421. Base64 encoding uses the 64-character alphabet encoding algorithm and output padding characters defined by PEM to encode the message body data. A Base64 encoded message is typically 33 percent larger than the original message. Base64 encoding creates a predictable increase in message size and is optimal for binary data and non-US-ASCII text. Typically, you won't see multiple encoding algorithms used in the same message. When no encoding algorithm has been used on the message body, the Content-Transfer-Encoding header field merely identifies the current condition of the message body data. The following values of the Content-Transfer-Encoding header field indicate that no encoding algorithms were used on the message body: 7bit This value indicates that the message body data is already in the RFC 2822 format. Specifically, this means that the following conditions must be true: All lines of text must be less than 998 characters long. All characters must be US-ASCII text that have character values from 1 through 127. The CR and LF characters can only be used together to indicate the end of a line of text. The whole message body may be 7bit, or part of the message body in a multipart message may be 7bit. If the multipart message contains other parts that have any binary data or non-US-ASCII text, that part of the message must be encoded using the Quotedprintable or Base64 encoding algorithms. Messages that have 7bit bodies can travel between SMTP messaging servers by using the standard DATA command. 8bit This value indicates that the message body data contains non-US-ASCII characters. Specifically, this means that the following conditions must be true: All lines of text must be less than 998 characters long. One or more characters in the message body have values larger than 127. The CR and LF characters can only be used together to indicate the end of a line of text. The whole message body may be 8bit, or part of the message body in a multipart message may be 8bit. If the multipart message contains other parts that have binary data, that part of the message must be encoded using the Quoted-printable or Base64 encoding algorithms. Messages that have 8bit bodies can only travel between SMTP messaging servers that support the 8BITMIME SMTP extension as defined in RFC 1652, such as servers running Exchange 2010, Exchange Server 2007, Exchange Server 2003, or Exchange 2000 Server. Specifically, this means that the following conditions must be true: The 8BITMIME keyword must be advertised in the server's EHLO response. Messages are still transferred by using the SMTP standard DATA command. However, the BODY=8BITMIME parameter must be added to the end of the MAIL FROM command. Binary This value indicates that the message body contains non-US-ASCII text or binary data. Specifically, this means that the following conditions are true: Any sequence of characters is allowed. There is no line length limitation. Binary message elements don't require encoding. Messages that have Binary bodies can only travel between SMTP messaging servers that support the BINARYMIME SMTP extension as defined in RFC 3030, such as servers running Exchange 2010, Exchange 2007, Exchange 2003, or Exchange 2000. Specifically, this means that the following conditions must be true: The BINARYMIME keyword must be advertised in the server's EHLO response. The BINARYMIME SMTP extension can only be used with the CHUNKING SMTP extension. Chunking enables large message bodies to be sent in multiple, smaller chunks. Chunking is also defined in RFC 3030. The CHUNKING keyword must also be advertised in the server's EHLO response. Messages are transferred using the BDAT command instead of the standard DATA command. The BODY=BINARYMIME parameter must be added to the end of the MAIL FROM command when the message has a message body. The values 7bit, 8bit, and Binary never exist together in the same multipart message. The values are mutually exclusive. The Quotedprintable or Base64 values may appear in a 7bit or 8bit multipart message body, but never in a Binary message body. If a multipart message body contains different parts composed of 7bit and 8bit content, the whole message is classified as 8bit. If a multipart message body contains different parts composed of 7bit, 8bit, and Binary content, the whole message is classified as Binary. ContentDisposition Attachment This header field instructs a MIME-enabled e-mail client on how it should display an attached file, and is described in RFC 2183. The values of this field may be Inline or Attachment. When the value of this field is Inline, the attachment is displayed in the message body. When the value of this field is Attachment, the attached file appears as a regular attachment separate from the message body. Other parameters are available when the value is Attachment, such as Filename, Creation-date, and Size.

Exchange 2010 and Outlook Message Formats

The following list describes the basic message formats available in Exchange 2010 and Microsoft Outlook:

Plain text A plain text message uses only US-ASCII text as described in RFC 2822. The message can't contain different fonts or other text formatting. The following two formats can be used for a plain text message: The message headers and the message body are composed of US-ASCII text. Attachments must be encoded by using Uuencode. Uuencode represents Unix-to-Unix encoding and defines an encoding algorithm to store binary attachments in the body of an e-mail message by using US-ASCII text characters. The message is MIME-encoded with a Content-Type value of text/plain, and a Content-Transfer-Encoding value of 7bit for the text parts of a multipart message. Any message attachments are encoded by using Quoted-printable or Base64 encoding. By default, when you compose and send a plain text message in Outlook, the message is MIME-encoded with a Content-Type value of text/plain. HTML An HTML message supports text formatting, background images, tables, bullet points, and other graphical elements. By definition, an HTML-formatted message must be MIME-encoded to preserve these formatting elements. Rich text format (RTF) RTF supports text formatting and other graphical elements. RTF is synonymous with the Transport Neutral Encapsulation Format (TNEF). TNEF and RTF can be used interchangeably. Only Outlook and a few other MAPI e-mail clients understand RTF messages. MAPI is a Microsoft-developed messaging architecture that enables multiple applications to interact with different messaging systems across a variety of hardware platforms. MAPI is built on the Component Object Model (COM) architecture. Outlook uses MAPI to communicate with mailboxes on a computer running Exchange 2010 that has the Mailbox server role installed. The rich text message format is completely different from the rich text document format available in Microsoft Word. TNEF TNEF is a Microsoft-specific format for encapsulating MAPI message properties. A TNEF message contains a plain text version of the message and an attachment that packages the original formatted version of the message. Typically, this attachment is named Winmail.dat. The Winmail.dat attachment includes the following information: Original formatted version of the message, including, for example, fonts, text sizes, and text colors

OLE objects, including, for example, embedded pictures or embedded Microsoft Office documents Special Outlook features, including, for example, custom forms, voting buttons, or meeting requests Regular message attachments that were in the original message The resulting plain text message can be represented in the following formats: RFC 2822-compliant message composed of only US-ASCII text with a Winmail.dat attachment encoded in Uuencode Multipart MIME-encoded message that has a Winmail.dat attachment A MAPI-compliant e-mail client that fully understands TNEF, such as Outlook, processes the Winmail.dat attachment and displays the original message content without ever displaying the Winmail.dat attachment. An e-mail client that doesn't understand TNEF may present a TNEF message in any of the following ways: The plain text version of the message is displayed, and the message contains an attachment named Winmail.dat, Win.dat, or some other generic name such as Attnnnnn.dat or Attnnnnn.eml where the nnnnn placeholder represents a random number. The plain text version of the message is displayed. The TNEF attachment is ignored or removed. The result is a plain text message. Messaging servers that understand TNEF can be configured to remove TNEF attachments from incoming messages. The result is a plain text message. Moreover, some e-mail clients such as Microsoft Outlook Express may not understand TNEF, but recognize and ignore TNEF attachments. The result is a plain text message. There are third-party utilities that can help convert Winmail.dat attachments. TNEF is understood by Exchange 2010, Exchange 2007, Exchange 2003, Exchange 2000, and Exchange Server version 5.5. TNEF messages are transferred between SMTP messaging servers by using the standard DATA command verb. TNEF is automatically used by Exchange based on the following situations: Exchange 2003 If the Exchange organization is in mixed mode, TNEF is used for messages transferred between Exchange servers in different routing groups. Exchange 2000 TNEF is used for messages transferred between Exchange servers in different routing groups. Summary Transport Neutral Encapsulation Format (STNEF) STNEF is equivalent to TNEF. However, STNEF messages are encoded differently than TNEF messages. Specifically, STNEF messages are always MIME-encoded and always have a Content-Transfer-Encoding value of Binary. Therefore, there's no plain text representation of the message, and there's no distinct Winmail.dat attachment contained in the body of the message. The whole message is represented by using only binary data. Messages that have a Content-Transfer-Encoding value of Binary can only be transferred between SMTP messaging servers that support and advertise the BINARYMIME and CHUNKING SMTP extensions as defined in RFC 3030. The messages are always transferred between SMTP messaging by using the BDAT command, instead of the standard DATA command. STNEF is understood by Exchange 2010, Exchange 2007, Exchange 2003, and Exchange 2000. STNEF is automatically used by Exchange if the following conditions are true: Exchange 2010 STNEF is used for all messages transferred between Exchange servers in the organization. Exchange 2007 STNEF is used for all messages transferred between Exchange servers in the organization. Exchange 2003 If the Exchange organization is in native mode, STNEF is used for all messages transferred between Exchange servers in the organization. Exchange 2000 STNEF is used for messages transferred between Exchange servers in the same routing group. An unsupported hotfix also enables Exchange 2000 to use STNEF for messages transferred between Exchange servers in different routing groups. Exchange never sends STNEF messages to external recipients. Only TNEF messages can be sent to recipients outside the Exchange organization.

Elements of Content Conversion

Content conversion is the act of correctly formatting a message for each external recipient. This conversion is performed by the categorizer on a Hub Transport server. The content conversion options that you can set in an Exchange organization can be described in the following categories:

TNEF conversion options These conversion options specify whether TNEF should be preserved or removed from messages that leave the Exchange organization. Message encoding options These options specify message encoding options, such as MIME and non-MIME character sets, message encoding, and attachment formats. These conversion and encoding options are independent of one another. For example, whether TNEF messages can leave the Exchange organization isn't related to the MIME encoding settings or plain text encoding settings of those messages. You can specify the content conversion at various levels of the Exchange organization as described in the following list:

Remote domain settings Remote domains define the settings for outgoing message transfers between the Exchange 2010 organization and domains outside the Active Directory forest. Even if you don't create remote domain entries for specific domains, there's a predefined remote domain named Default that applies to all remote address spaces (*). Mail user and mail contact settings Mail users resemble mail contactsboth have external e-mail addresses and contain information about people outside the Exchange organization. The main difference is mail users have security contexts that can be used to log on to the Active Directory domain and access resources to which they have been granted permission. Outlook settings In Outlook, you can set the message formatting and encoding options described in the following list: Message format You can set the default message format for all messages. You can override the default message format as you compose a specific message. Internet message format You can control whether TNEF messages are sent to remote recipients or whether they are first converted to a more compatible format. You can also specify various message encoding options for messages sent to remote recipients. These settings don't apply to messages sent to recipients in the Exchange organization. Internet recipient message format You can control whether TNEF messages are sent to specific recipients or whether they are first converted to a more compatible format. You can set the conversion options for specific contacts in your Contacts folder, and you can override the conversion options for a specific recipient in the To, Cc, or Bcc fields as you compose a message. These conversion options aren't available for recipients in the Exchange organization. Internet recipient message encoding options You can control the MIME or plain text encoding options for specific contacts in your Contacts folder, and you can override the conversion options for a specific recipient in the To, Cc, or Bcc fields as you compose a message. These conversion options aren't available for recipients in the Exchange organization. International options You can control the character sets used in messages.

TNEF Conversion Options

You can specify the TNEF conversion options at the following levels:

Remote domain settings Mail user and mail contact settings Outlook settings, including: Message format Internet message format Internet recipient message format For detailed information, see TNEF Conversion Options.

Message Encoding Options

You can specify the message options at the following levels:

Remote domain settings Mail user and mail contact settings Outlook settings, including: Message format Internet message Internet recipient message format Message character set encoding options For detailed information, see Message Encoding Options.

Content Conversion Performed by the Store Driver

The store driver also performs content conversion. The store driver exists on Hub Transport servers to transport messages between mailboxes on Mailbox servers and the Submission queue. Specifically, the store driver transports messages from the sender's Outbox to the Submission queue on the Hub Transport server, and the store driver transports the messages from the Submission queue on the Hub Transport server to the recipient's Inbox. The store driver converts all outgoing messages from MAPI and converts all incoming messages to MAPI. Content conversion tracing captures these store driver conversion failures. For more information, see Content Conversion Tracing.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

TNEF Conversion Options

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 The content conversion options that you can set in an Exchange organization can be described in the following categories:

TNEF conversion options These conversion options specify whether Transport Neutral Encapsulation Format (TNEF) should be preserved or removed from messages that leave the Exchange organization. Message encoding options These options, such as MIME and non-MIME character sets, specify message encoding and attachment formats. This topic describes the TNEF conversion options that you can specify at the following levels:

Remote domain settings Mail user and mail contact settings Microsoft Outlook settings Message format Internet message format Internet recipient message format

TNEF Conversion Options for Messages Sent to Remote Domains

When you configure TNEF conversion options for a remote domain, those TNEF conversion options are applied to all messages sent to that domain. For remote domains in your organization, you have the following configuration options for TNEF conversion:

TNEF use enabled TNEF is used for all messages sent to the remote domain. TNEF use disabled TNEF is never used for any messages sent to the remote domain. Unspecified TNEF messages aren't specifically allowed or prevented for recipients in the remote domain. Whether TNEF messages are sent to recipients in the remote domain depends on the specific setting on the mail contact or mail user, or the setting specified by the sender in Outlook. This is the default setting. In Microsoft Exchange 2010, you can set the TNEF conversion options for messages sent to a remote domain in the Exchange Management Shell or on the Remote Domains tab in the Exchange Management Console (EMC). For more information about configuring TNEF options for a remote domain, see the following topics:

Configure Remote Domain Properties Set-RemoteDomain

TNEF Conversion Options for Messages Sent to Mail Users and Mail Contacts
When you configure TNEF conversion options for a mail contact or a mail user, those TNEF conversion options are applied to all messages sent to that specific recipient. For mail contacts and mail users in your organization, you have the following configuration options for TNEF conversion:

Always TNEF is used for all messages sent to the recipient. Never TNEF is never used for any messages sent to the recipient. Use default settings TNEF messages aren't specifically allowed or prevented for the mail user or mail contact. Whether TNEF messages are sent to the recipient depends on the specific setting for the corresponding remote domain or the setting specified by the sender in Outlook. This is the default setting. Note: In both the EMC and the Shell, the TNEF conversion settings are referred to as MAPI rich text format. You can set the TNEF conversion options for messages sent to mail users and mail contacts in the Shell or in the Recipient Configuration node in the EMC. For more information about configuring TNEF options for these recipient types, see the following topics:

Configure Mail Contact Properties Configure Mail User Properties Set-MailContact Set-MailUser

TNEF Conversion Options for Messages Available in Outlook

Senders can control the default TNEF message conversion options for TNEF messages sent to all recipients outside the Exchange organization. These options are called Internet message format options. The options only apply to remote recipients, and not to recipients in the Exchange organization. Note: The following options define how messages containing Outlook rich text are handled when sent to external recipients. If the message format you're using is HTML or plain text, these settings dont apply. You have the following TNEF conversion options in Outlook:

Convert to HTML format This is the default option. Any TNEF messages sent to remote recipients are converted to HTML. Any formatting in the message should closely resemble the original message. MIME-encoded HTML messages are supported by many, but not all, e-mail clients.

Convert to Plain Text format Any TNEF messages sent to remote recipients are converted to plain text. Any formatting in the message is lost. Send using Outlook Rich Text Format Any TNEF messages sent to remote recipients remain TNEF messages. These options can be configured in Outlook by navigating to Tools > Options > Mail Format, and then clicking Internet Format. Senders can also control the default TNEF message conversion options for TNEF messages sent to specific recipients outside the Exchange organization. These options are called Internet recipient message format options. The options only apply to remote recipients stored in your Contacts folder, and not to recipients in the Exchange organization. You have the following TNEF conversion options for remote recipients in your Contacts folder:

Let Outlook decide the best sending format This is the default setting. This setting forces Outlook to use the TNEF conversion option that's specified by the default Internet format. The possible values are Convert to HTML format, Convert to Plain Text format, or Send using Outlook Rich Text Format. Therefore, the TNEF message may be left as TNEF, converted to HTML, or converted to plain text. If you want to make sure that the TNEF message remains TNEF for this recipient, you should change this setting from Let Outlook decide the best sending format to Send using Outlook Rich Text format. Send Plain Text only Any TNEF messages sent to the recipient are converted to plain text. Any formatting in the message is lost. Send using Outlook Rich Text format Any TNEF messages sent to remote recipients remain TNEF messages. These options can be configured for a contact in Outlook by opening that contact and then double-clicking the E-mail field and selecting Internet format.

Order of Precedence for TNEF Conversion Options

Exchange 2010 uses the order of precedence as described in the following list to determine the TNEF conversion options for outgoing messages sent to recipients outside the Exchange organization:

1. Outlook settings 2. Mail user or mail contact settings 3. Remote domain settings The list specifies the order of precedence from lowest to highest. A setting made at a higher level overrides a setting made at a lower level. Exchange never sends Summary Transport Neutral Encoding Format (STNEF) messages to external recipients. Only TNEF messages can be sent to recipients outside the Exchange organization.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Message Encoding Options

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 The content conversion options that you can set in an Exchange organization can be described in the following categories:

TNEF conversion options These conversion options specify whether Transport Neutral Encapsulation Format (TNEF) should be preserved or removed from messages that leave the Exchange organization. Message encoding options These options specify message encoding options, such as MIME and non-MIME character sets, message encoding, and attachment formats. This topic describes message encoding options that you can specify at the following levels:

Remote domain settings Mail user and mail contact settings Microsoft Outlook settings Message format Internet message format Internet recipient message format Message character set encoding options

Message Encoding Options for Messages Sent to Remote Domains

When you configure message encoding options for a remote domain, the specific settings are applied for all messages sent to that domain. For remote domains in your organization, you have the following configuration options for message encoding:

Content type You can specify the content type for MIME messages sent to the recipients in the remote domain. You can use of the following settings: MimeHtmlText All messages are converted to MIME messages that use HTML formatting, unless the original message is a text message. If the original message is a text message, the outgoing message will be a MIME message that uses text formatting. This is the default setting. MimeText All messages are converted to MIME messages that use text formatting. MimeHtml All messages are converted to MIME messages that use HTML formatting. Note: You can only configure this setting using the Exchange Management Shell. Line wrap size You can specify the maximum number of characters that can exist on a single line of text in the body of the e-mail message. Older e-mail client applications may prefer 78 characters per line. MIME character set The character set that you specify will only be used for MIME messages that don't have their own character set specified. Setting this parameter won't overwrite character sets that are already specified in the outgoing mail. For a list of valid character set names, see Supported Character Sets for Remote Domain Configuration. Non-MIME character set This parameter is used if either of the following conditions are true: Incoming messages from a remote domain are missing the value of the charset= parameter in the MIME Content-Type: header field. Outgoing messages to a remote domain are missing the value of the MIME character set. For a list of valid character set names, see Supported Character Sets for Remote Domain Configuration. In Microsoft Exchange Server 2010, you can set the message encoding options for recipients in remote domains in the Shell or on the Remote Domains tab in the Exchange Management Console (EMC). For more information, see the following topics:

Configure Remote Domain Properties Set-RemoteDomain

Message Encoding Options for Mail Users and Mail Contacts

When you configure message encoding options for a mail contact or a mail user, that option is applied to all messages sent to that specific recipient. For mail contacts and mail users in your organization, you have the following configuration options for message encoding:

UsePreferMessageFormat This parameter specifies whether the message format settings configured for the mail contact override the global settings configured for the remote domain. If you disable this setting, Exchange ignores other message encoding options for this recipient and the message encoding is determined by the configuration of the remote domain or the settings configured by the message sender. MessageFormat This parameter specifies the message format. You can either specify Text or Mime as the message format. The value of this setting is dependent on the MessageBodyFormat parameter. If the message body format is Html or TextAndHtml, you must set this parameter to Mime. MessageBodyFormat This parameter specifies the message body format. You can specify Text, Html, or TextAndHtml. The value of this setting is dependent on the MessageFormat parameter. If the message format is Text, you must also set this parameter to Text. MacAttachmentFormat This parameter specifies the Apple Macintosh operating system attachment format for messages. You can specify BinHex, UuEncode, AppleSingle, or AppleDouble. The value of this setting is dependent on the MessageFormat parameter. If the message format is set to Text, you must set this parameter to either BinHex or UuEncode. If the message format is set to Mime, you must set this parameter to BinHex, AppleSingle or AppleDouble. You must use the Shell to set the message encoding options for mail users and mail contacts. For more information, see the following topics:

Enable-MailContact New-MailContact Set-MailContact Enable-MailUser New-MailUser

Set-MailUser

Message Encoding Options Available in Outlook

As a sender, you can specify message encoding options in Outlook at any of the following stages:

By configuring the default message format to be either plain text or HTML. By setting the message format as you're composing it to either plain text or HTML using the Format area in the Options tab. By configuring the message encoding options for messages that are sent to all recipients outside the Exchange organization. These options are called Internet message format options. The options only apply to remote recipients, and not to recipients in the Exchange organization. These options can be configured in Outlook by navigating to the Tools > Options > Mail Format, and clicking Internet Format. By configuring the message encoding options for messages that are sent to specific recipients outside the Exchange organization. These options are called Internet recipient message format options. The options only apply to remote recipients in your Contacts folder, and not to recipients in the Exchange organization. These options can be configured for a contact in Outlook by opening that contact and then double-clicking the E-mail field and selecting Send Options. By default, Outlook uses automatic character set message encoding by scanning the whole text of the outgoing message to determine the appropriate encoding to use for the message. This setting applies to messages that you send to Internet recipients and recipients in the Exchange organization. However, you can bypass this and specify a preferred encoding for outgoing messages. These options can be configured in Outlook by navigating to Tools > Options > Mail Format, and clicking International Options.

Order of Precedence for Message Encoding Options

Exchange 2010 uses the order of precedence as described in the following list to determine the message encoding options for outgoing messages sent to recipients outside the Exchange organization:

1. Remote domain settings 2. Outlook settings 3. Mail user or mail contact settings The list specifies the order of precedence from lowest to highest. A setting made at a higher level may override a setting made at a lower level. The following table describes the order of precedence from lowest priority to highest priority for message character set encoding options.

Order of precedence from lowest priority to highest priority for message character set encoding options
Source Set-RemoteDomain Set-RemoteDomain Outlook setting Parameter CharacterSet NonMimeCharacterSet Message character set encoding Values Specified Specified

Auto-select Specified

The value of the NonMimeCharacterSet parameter from the Set-RemoteDomain cmdlet is used to assign a character set to the following types of messages:

Outgoing messages to a configured remote domain that don't contain a specified character set Incoming messages from a configured remote domain that don't contain a specified character set The value of the Windows ANSI code page for the Hub Transport server is used to assign a character set to the following types of messages:

Internal messages that don't contain a specified character set Internal messages that contain a specified character set, but don't contain a specified server code page If a message contains a specified but invalid character set, the Hub Transport server tries to replace the invalid character set with a valid character set. The following table describes the order of precedence from lowest priority to highest priority for plain text message encoding options.

Order of precedence from lowest priority to highest priority for plain text message encoding options
Source SetRemoteDomain Parameter LineWrapSize Values

From 0 through 132 unlimited

Outlook settings Outlook settings

Message format Internet message format

Plain text Plain text options: Encode attachments in UuEncode format when you send a plain text message Automatically wrap text at nn characters

Outlook settings

Internet recipient message format

Plain text format: Encode attachments in UuEncode attachment format

Use BinHex Mac attachment format

Set-MailUser SetMailContact

UsePreferMessageFormat $true $false If the value is $false or if the recipient isn't defined as a mail user or mail contact in the Exchange organization, the mail user or mail contact settings are ignored.

Set-MailUser SetMailContact Set-MailUser SetMailContact Set-MailUser SetMailContact

MessageFormat

Text

MessageBodyFormat

Text

MacAttachmentFormat

BinHex UuEncode

The following table describes the order of precedence from lowest priority to highest priority for MIME message encoding options.

Order of precedence from lowest priority to highest priority for MIME message encoding options
Source SetRemoteDomain Parameter ContentType MimeHtmlText MimeText MimeHtml Values

Outlook settings

Message format

Plain text HTML

Outlook settings

Internet recipient message format

MIME message format Plain text Include both plain text and HTML HTML

Set-MailUser SetMailContact

UsePreferMessageFormat

$true $false If the value is $false or if the recipient isn't defined as a mail user or mail contact in the Exchange organization, the mail user or mail contact settings are ignored.

Set-MailUser SetMailContact

MessageFormat

Text Mime

Set-MailUser SetMailContact

MessageBodyFormat Text Html TextAndHtml

Set-MailUser SetMailContact

MacAttachmentFormat

BinHex AppleSingle AppleDouble

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Content Conversion Tracing

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-11-06 Content conversion tracing captures failures in the content conversion that's performed by the store driver on inbound and outbound messages on a computer running Microsoft Exchange Server 2010 that has the Hub Transport server role installed. The categorizer on a Hub Transport server is responsible for the content conversion of all messages sent to external recipients. However, the store driver on a Hub Transport server is responsible for the content conversion of messages sent to and from mailbox recipients. Specifically, the store driver must convert outbound messages from mailbox users from MAPI to MIME. The store driver must also convert inbound messages for mailbox users from MIME to MAPI. Content conversion tracing is responsible for capturing these MAPI conversion failures. Content conversion tracing doesn't capture any content conversion failures that the categorizer encounters as it converts messages sent to external recipients. Contents Configuring Content Conversion Tracing How Content Conversion Tracing Works Considerations for Content Conversion Tracing

Configuring Content Conversion Tracing

Content conversion tracing is controlled by the following parameters in the Set-TransportServer cmdlet in the Exchange Management Shell:

ContentConversionTracingEnabled This parameter enables or disables content conversion. Valid values for this parameter are $True and $False. The default value is $False. If the Exchange organization contains multiple Hub Transport servers, you must enable content conversion tracing on each Hub Transport server responsible for delivery of messages to Mailbox servers. PipelineTracingPath Although this parameter is associated with pipeline tracing, it also specifies the root location of the content conversion tracing files. By default, the value of the PipelineTracingPath parameter is C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing. The path must be local to the Exchange 2010 computer. Content conversion creates a folder named ContentConversionTracing inside the path specified by the PipelineTracingPath parameter. Inside the ContentConversionTracing folder, content conversion creates two subfolders: InboundFailures and OutboundFailures. The InboundFailures folder contains the information from inbound message content conversion failures. The OutboundFailures folder contains the information from outbound message content conversion failures. The maximum size for all the files in the InboundFailures folder is 128 megabytes (MB). The maximum size for all the files in the OutboundFailures folder is 128 MB. The content conversion tracing directories don't use circular logging to remove old files, depending on the age or size of the files. As soon as the maximum size for a folder is reached, content conversion tracing stops writing information to the folder. If you want to make sure that the maximum folder size limits aren't exceeded, you can create a scheduled task that periodically moves the content conversion tracing files to a different location. The permissions required on the folders and subfolders used in content conversion tracing are as follows:

Administrators: Full Control Network Service: Full Control System: Full Control

Caution: Content conversion tracing copies the complete contents of e-mail messages. To avoid unwanted exposure of confidential information, you must set appropriate security permissions on the location of the content conversion tracing files. Return to top

How Content Conversion Tracing Works

When the content conversion of an inbound message fails, a delivery status notification (DSN) that has the status code 5.6.0 is sent to the message sender. If content conversion tracing is enabled, the failure information is recorded at the time that the 5.6.0 DSN message is generated. Each content conversion error generates two separate files. A content conversion error that occurs when an inbound message is converted from MIME to MAPI generates the following two files in the InboundFailures folder:

<GUID>.eml This file contains the failed message in text format. <GUID>.txt This file contains the exception description, conversion results, conversion options, and message size limits imposed on all messages by the store driver. A content conversion error that occurs when an outbound message is converted from MAPI to MIME generates the following two files in the OutboundFailures folder:

<GUID>.msg This file contains the failed message in the Microsoft Outlook message format.

<GUID>.txt This file contains the exception description, conversion results, conversion options, and message size limits imposed on all messages by the store driver. The placeholder <GUID> is the same in both file names. Each content conversion error generates a different GUID that's used in the file names of the corresponding message and text files. An example of a GUID that's used in the file names is 038b930e-61fd-4bfd-b9b4-0374c18b73f7. Return to top

Considerations for Content Conversion Tracing

You can leave content conversion tracing enabled for proactive monitoring. Or, you can enable content conversion tracing to troubleshoot a specific failure event. You can usually reproduce inbound content conversion failures by asking the recipient of the 5.6.0 DSN message to resend the original message. Inbound content conversion failures are the most common. Some of the reasons for inbound content conversion errors include the following:

Violations of message size limits These message size limits are imposed by the store driver to help prevent denial of service attacks (DoS). These message limits are listed in the <GUID>.txt file. These message limits include the following: MaxMimeTextHeaderLength This limit specifies the maximum number of text characters that can be used in a MIME header. The value is 2000. MaxMimeSubjectLength This limit specifies the maximum number of text characters that can be used in the subject line. The value is 255. MSize This limit specifies the maximum message size. The value is 2147483647 bytes. MaxMimeRecipients This limit specifies the total number of recipients allowed in the To, Cc, and Bcc fields. The value is 12288. MaxRecipientPropertyLength This limit specifies the maximum number of text characters that can be used in a recipient description. The value is 1000. MaxBodyPartsTotal This limit specifies the maximum number of message parts that can be used in a MIME multipart message. The value is 250. MaxEmbeddedMessageDepth This limit specifies the maximum number of forwarded messages that can exist in a message. The value is 30. For more information about configurable message size limits used in Hub Transport servers or Edge Transport servers, see Understanding Message Size Limits. Failure to convert an inbound iCalendar message to a meeting request RFC 2445 defines iCalendar as a standard for calendar data exchange. Specific causes of the conversion failure include the following: Incorrect use of iCalendar by the sending agent. Constructs of iCalendar that can't be supported by the Outlook or Exchange calendar schema. Conversion failures of iCalendar don't result in the sender receiving a 5.6.0 DSN message. Instead, the message is delivered with an attached .ics file that contains the iCalendar message body. Failures caused by badly formatted MIME messages Unsolicited commercial e-mail or spam messages may have formatting errors in the message header, such as unmatched quotation marks in recipient descriptions. A much smaller number of failures caused by badly formatted MIME messages are considered bugs. Outbound content conversion failures are much less common than inbound failures. When outbound failures occur, they are usually caused by Exchange code bugs or corrupted message content. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Delivery Agents

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-12-17 Delivery agents are responsible for delivering messages addressed to foreign systems that don't use the SMTP protocol. Each delivery agent works with a Delivery Agent connector. When a message is routed to a Delivery Agent connector, the associated delivery agent performs the content conversion and message delivery. Delivery agents are a significant improvement over Foreign connectors in handling non-SMTP messages in your Exchange organization. Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents Delivery Agents Adding Delivery Agents to Your Organization Events Used by Delivery Agents

Delivery Agents

A delivery agent is a custom agent that can:

Establish a connection to the foreign system for message delivery. Retrieve messages from the remote delivery queues on Hub Transport servers. Deliver messages to the foreign system. Provide acknowledgement for each successful message delivery. While the Foreign connector architecture remains in Microsoft Exchange Server 2010, we recommend using delivery agents for routing messages to non-SMTP systems whenever possible. Delivery agents provide the following benefits:

They allow queue management of messages routed to foreign systems using the familiar queue management tools. Because the messages no longer need to be written to and read from the file system, message delivery performance is improved. They provide access to message properties with rich events for agent developers. Development time for a delivery agent is faster than implementing a Foreign connector because the delivery agent can use the message representation and management features of Exchange. You can now be sure that the messages are delivered to the foreign system as opposed to just being written to the Drop directory. The usage of Delivery Agent connectors allows service level agreement (SLA) analysis because it's now possible to track the latency of message delivery to the foreign system. Return to top

Adding Delivery Agents to Your Organization

To use a delivery agent in your organization, you have to complete the following:

Acquire the delivery agent. Typically, delivery agents are written by third parties. Exchange 2010 comes with only one Delivery Agent connector by default: the Text Messaging Delivery Agent connector. Install the delivery agent on your Hub Transport servers that will act as source servers for the Delivery Agent connectors. Create a Delivery Agent connector for the specific protocol. When all of these steps are completed, messages to the foreign systems will be routed through the Delivery Agent connectors and processed by the delivery agent.

Delivery Agent Connectors

Don't confuse the Delivery Agent connectors with the actual delivery agents. Delivery Agent connectors are configured to make routing decisions. The Delivery Agent connectors handle queuing messages to be processed by the delivery agents; much like Send connectors or Routing Group connectors are used for SMTP delivery. Delivery Agent connectors ensure that the messages destined to the foreign system are inserted into the appropriate queues on the Hub Transport servers that are used for delivering messages to the foreign systems. After the messages are queued, Connection Manager invokes the delivery agent to handle the actual delivery of the message to the foreign system. Return to top

Events Used by Delivery Agents

Delivery agents act on the following events raised by the Connection Manager component:

OnOpenConnection This event is raised when there are messages in the queue to be delivered to the foreign system. It notifies the delivery agent to initiate a connection to the foreign system. OnDeliverMailItem This event notifies the delivery agent to retrieve the next item from the queue. OnCloseConnection This event is raised when there are no more messages in the queue to be delivered to the foreign system. It notifies the delivery agent to close the connection to the foreign system. In a typical delivery scenario, the following interaction between Connection Manager and the delivery agent takes place:

1. Connection Manager detects messages queued for delivery to the foreign system. 2. Connection Manager invokes the delivery agent using the OnOpenConnection event. 3. The delivery agent establishes a connection with the foreign system. After the connection is established, it notifies Connection Manager using the RegisterConnection method. 4. Connection Manager raises the OnDeliverMailItem event. 5. The delivery agent retrieves the message from the queue and delivers it to the foreign system. After delivery is complete, it provides acknowledgement to Connection Manager. 6. If there are additional messages in the queue, steps 4 and 5 are repeated until all messages are delivered. 7. Connection Manager raises the OnCloseConnection event. 8. The delivery agent closes the connection with the foreign system and notifies Connection Manager using the UnRegisterConnection method.

Retry Situations
The following are the situations where messages or the entire Delivery Agent connector queue would end up in the Retry state:

After Connection Manager raises the OnOpenConnection event, if no delivery agents respond with the RegisterConnection method, the entire queue for that Delivery Agent connector is put into retry. If the delivery agent doesn't provide an acknowledgement for a specific message, that message is put into retry. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding DSNs and NDRs

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-05-20 This topic describes how to read and interpret non-delivery report (NDR) delivery status notification (DSN) messages in Microsoft Exchange Server 2010.

NDR Sections
In Exchange 2010, NDRs have been designed to make them easier to read and understand by both end-users and administrators. Information that is displayed in an NDR is separated into the following two areas:

A user information section A Diagnostic information for administrators section The information in each section is targeted to the readers of that section. The user information section appears first and contains feedback to help the user understand in nontechnical terms why the delivery of the message failed. The Diagnostic information for administrators section provides deeper technical information such as the original message headers, to help e-mail administrators troubleshoot a delivery issue that may exist. The following figure shows the user information section and Diagnostic information for administrators section of an NDR.

User Information Section

The user information section of an NDR generated by Exchange 2010 contains information that you want to communicate to an end-user who has sent a message that is later returned with an NDR. The text that is displayed in this section is inserted by the Exchange server that generated the NDR. The text in the user information section is designed to help the end-user determine why the message was rejected and how to resend the message successfully if the message should be resent. When applicable, the fully qualified domain name (FQDN) of the server that rejected the message is included in the user information section. If delivery fails to more than one recipient, the e-mail address of each recipient is listed and the reason for the failure is included in the space below the recipient's e-mail address. You can modify the text in the user information section by using the New-SystemMessage cmdlet. By creating a custom message, you can provide specific information to end-users, such as a telephone number to use to contact the helpdesk department or a hyperlink to use to obtain self-service support. For more information about how to customize the text that is displayed in the user information section, Create a Custom DSN Message.

Diagnostic Information for Administrators

The Diagnostic information for administrators section contains more detailed information about the specific error that occurred during delivery of the message, the server that generated the NDR, and the server that rejected the message. The following fields are present in most NDRs and are visible in the "NDR sections"

figure earlier in this topic:

Generating server The generating server is the SMTP server that created the NDR. The generating server takes the enhanced status code that is explained later in this topic. This code creates an easy-to-read NDR. If no remote server is listed below the e-mail address of the sender in the Diagnostic information for administrators section, the generating server is also the server that rejected the original e-mail message. If message delivery fails when the message is sent to another recipient in the Exchange organization, the same server typically rejects the original message and generates the NDR. Rejected recipient The rejected recipient is the e-mail address of the recipient to which delivery of the original message failed. If delivery to more than one recipient has failed, the e-mail address for each recipient is listed. The rejected recipient field also contains the following sub-fields for each e-mail address listed: Remote server The remote server field contains the FQDN of the server that rejects delivery of the message during the Simple Mail Transfer Protocol (SMTP) conversation. The remote server field is only populated when delivery has been attempted to a remote server, and that delivery attempt has been rejected before the receiving server successfully acknowledges the message after the message body is sent. If the original message is successfully acknowledged by the receiving server and is then rejected because of content restrictions, for example, the remote server field is not populated. Enhanced status code The enhanced status code is the code returned by the server that rejected the original message. The enhanced status code indicates why the original message was rejected. The enhanced status code is not rewritten by Exchange 2007 but is used to determine what text to display in the user information section. The enhanced status codes you're most likely to encounter are listed in "Common Enhanced Status Codes" later in this topic. For a detailed list of enhanced status codes, see RFC 3463. SMTP response The SMTP response is the machine readable text returned by the server that rejected the original message. The SMTP response typically contains a short string that provides an explanation of the enhanced status code that is also returned. The SMTP response is not rewritten by Exchange 2010. Additionally, this response is always presented in US-ASCII format. Original message headers The original message headers section contains the message headers of the rejected message. These headers can provide useful diagnostic information, such as information that can help you determine the path that the message took before it was rejected or whether the To field matches the e-mail address that is specified in the rejected recipient field.

Examples of NDR Messages

The following sections provide examples of two ways that NDR messages can be generated:

By the same server By different servers

NDR Generated and Original Message Rejected by the Same Server

The following example shows what happens when a remote e-mail organization accepts delivery of an e-mail message through an Edge Transport server, and then rejects that message because of a policy restriction on the recipient's mailbox. In this case, the sender is not allowed to send messages to the recipient. Edge Transport servers do not perform message size validation so the Edge Transport server in this example accepts the message because it has a valid recipient address and the message does not violate another content restrictions. Because the remote e-mail organization accepts the whole message, including the message contents, the remote e-mail organization is responsible for rejecting the message and for generating the NDR message to be sent to the sender.

Also, messages that are rejected when they are sent to recipients that are part of the same Exchange 2010 organization are typically rejected by the same e-mail server that generates the NDR message. Messages sent to local recipients can be rejected for various reasons, such as mailboxes that have exceeded their quota, lack of authorization to send messages to the recipient address, or hardware failures that result in an extended loss of connectivity to other servers in the organization. In both situations, no remote server is included under the e-mail address of the recipients listed in the NDR message.

NDR Generated and Original Message Rejected by Different Servers

The following example shows what happens when a remote e-mail organization rejects delivery of an e-mail message before it ever accepts the message. In this example, the remote server rejects the message and returns an enhanced status code to the local sending server because the specified recipient does not exist. The rejection happens before the receiving server ever acknowledges the message. Because the receiving server doesn't successfully acknowledge the message, the receiving server is not responsible for the message. Therefore, the local sending server generates the NDR message and sends it to the sender of the original message.

Common Enhanced Status Codes

The following table contains a list of the enhanced status codes that are returned in NDRs for the most common message delivery failures.

Enhanced status code 4.3.1

Description

Possible cause

Additional information

Insufficient system resources

An out-of-memory error occurred. A resource problem, such as a full disk, can cause this problem. Instead of getting a disk full error, you might be getting an out-of- memory error. This NDR is generated when a queue has been frozen.

Ensure that your Exchange server has enough disk storage.

4.3.2

System not accepting network messages

You can resolve this condition by unfreezing the queue.

4.4.1

Connection timed out

The destination server is not responding. Transient network conditions can cause this error. The Exchange server tries automatically to connect to the server again and deliver the mail. If delivery fails after multiple attempts, an NDR with a permanent failure code is generated. A connection dropped between the servers. Transient network conditions or a server that is experiencing problems can cause this error. The sending server will retry delivery of the message for a specific time period, and then generate further status reports.

Monitor the situation. This may be a transient problem that may correct itself.

4.4.2

Connection dropped

Monitor the situation as the server retries delivery. This may be a transient problem that may correct itself. This situation can also occur when the message size limit for the connection is reached, or if the message submission rate for the client IP address has exceeded the configured limit.

4.4.7

Message expired

The message in the queue has expired. The sending server tried to relay or deliver the message, but the action was not completed before the message expiration time occurred. This message can also indicate that a message header limit has been reached on a remote server, or some other protocol time-out occurred while communicating with the remote server. This situation is a permanent failure. Possible causes include: There is no route for the given address space; for example, an SMTP connector is configured, but this address does not match. DNS returned an authoritative host that was not found for the domain. An SMTP error occurred.

This message usually indicates an issue on the receiving server. Check the validity of the recipient address, and determine if the receiving server is configured correctly to receive messages. You may have to reduce the number of recipients in the message header for the host about which you are receiving this error. If you send the message again, it is placed in the queue again. If the receiving server is available, the message is delivered.

5.0.0

HELO / EHLO requires domain address

Some potential resolutions include: On one or more SMTP connectors, add an asterisk (*) value as the SMTP address space. Verify that DNS is working.

5.1.0

Sender denied

This NDR is caused by a general failure (bad address failure). An e-mail address or another attribute could not be found in Active Directory. Contact entries without the targetAddress attribute set can cause this problem. Another possible cause could be that the homeMDB attribute of a user could not be determined. The homeMDB attribute corresponds to the Exchange server on which the user's mailbox resides. Another common cause of this NDR is if you used Microsoft Office Outlook to save your email message as a file, and then someone opened the message offline and replied to the message. The message property only preserves the legacyExchangeDN attribute when Outlook delivers the message, and therefore the lookup could fail. This failure may be caused by the following conditions: The recipient e-mail address was entered incorrectly by the sender. No recipient exists in the destination email system. The recipient mailbox has been moved and the Microsoft Office Outlook recipient cache on the sender's computer has not updated. An invalid legacy domain name (DN) exists for the recipient mailbox Active Directory.

Either the recipient address is incorrectly formatted, or the recipient could not be correctly resolved. The first step in resolving this error is to check the recipient address and send the message again.

5.1.1

Bad destination mailbox address

This error typically occurs when the sender of the message incorrectly enters the e-mail address of the recipient. The sender should check the recipient's e-mail address and send again. This error can also occur if the recipient e-mail address was correct in the past but has changed or has been removed from the destination e-mail system. If the sender of the message is in the same Exchange organization as the recipient, and the recipient mailbox still exists, determine whether the recipient mailbox has been relocated to a new e-mail server. If this is the case, Outlook may not have updated the recipient cache correctly. Instruct the sender to remove the recipient address from sender's Outlook recipient cache and then create a new message. Resending the original message will result in the same failure. Other issues may cause this error, such as an invalid legacy distinguished name (DN) in Active Directory. Examine and correct the legacy DN of the recipient's mailbox. Then instruct the sender to remove the recipient address from sender's Outlook recipient cache and then create a new message. Resending the original message will result in the same failure. Verify that the recipient's address was entered correctly. If the recipient's address is in a non-SMTP e-mail system that you specifically want to provide mail delivery to, you will need to add the appropriate type of connector to your topology and configure it to provide service to the recipient's e-mail system.

5.1.2

Invalid X.400 address

The recipient has a non-SMTP address that can't be matched to a destination. The address does not appear to be local, and there are no connectors configured with address spaces that contain the recipient's address. This message indicates that the recipient address appears incorrectly on the message.

5.1.3

Invalid recipient address

Either the recipient address is formatted incorrectly, or the recipient could not be correctly resolved. The first step in resolving this error is to check the recipient address and send the message again. Also, examine the SMTP recipient policy and ensure that each mail domain for which you want to accept mail appears correctly. This error typically occurs because of a misconfiguration in Active Directory. Possibly because of replication problems, two recipient objects in Active Directory have the same SMTP address or Exchange Server (EX) address.

5.1.4

Destination mailbox address ambiguous

Two or more recipients in the Exchange organization have the same address.

5.1.7

Invalid address

The sender has a malformed or missing SMTP address, the mail attribute in the directory service. The mail item cannot be delivered without a valid mail attribute. The mailbox cannot be accessed. The mailbox

Check the sender directory structure, and determine if the mail attribute exists.

5.2.1

Mailbox

Check to see if the recipient database is online, the recipient mailbox is disabled,

cannot be accessed 5.2.2 Mailbox full

may be offline, disabled, or the message has been quarantined by a rule.

or the message has been quarantined.

The recipient's mailbox has exceeded its storage quota and is no longer able to accept new messages.

This error occurs when the recipient's mailbox has exceeded its storage quota. The recipient must reduce the size of the mailbox or the administrator must increase the storage quota before delivery can be successful. If the recipient resides in the local Exchange 2010 organization, see Configure Storage Quotas for a Mailbox. Send the message again without attachments, or set the server or the client-side limit to allow a larger message size limit.

5.2.3

Message too large

The message is too large, and the local quota is exceeded. For example, a remote Exchange user might have a restriction on the maximum size of an incoming message. The recipient is a misconfigured dynamic distribution list. Either the filter string or the base DN of the dynamic distribution list is invalid. When the Exchange remote server reaches capacity of its disk storage to hold mail, it could respond with this NDR. This error usually occurs when the sending server is sending mail with an ESMTP BDAT command. This error also indicates a possible SMTP protocol error. The message exceeds a size limit configured on a transport or mailbox database and can't be accepted. This failure can be generated by either the sending e-mail system or the recipient e-mail system.

5.2.4

Mailing list expansion problem

Set the categorizer event logging level to at least the minimum level, and send another message to the dynamic distribution list. Check the application event log for a 6025 event or a 6026 event detailing which attribute is misconfigured on the dynamic distribution list object. Ensure that the remote server has enough storage capacity to hold mail. Check the SMTP log.

5.3.3

Unrecognized command

5.3.4

Message too big for system

This error occurs when the size of the message that was sent by the sender exceeds the maximum allowed message size when passing through a transport component or mailbox database. The sender must reduce the size of the message for the message to be successfully delivered. For more information about how to configure message size limits in an Exchange 2010 organization, see Configure Message Size Limits for a Mailbox or a Mail-Enabled Public Folder. Check the configuration of the server's connectors for loops, and ensure that each connector is defined by a unique incoming port. If there are multiple virtual servers, ensure that none are set to "All Unassigned."

5.3.5

System incorrectly configured

A mail-looping situation was detected, which means that the server is configured to loop mail back to itself.

5.4.4

Invalid arguments

This NDR occurs if no route exists for message delivery, or if the categorizer could not determine the next-hop destination. A configuration error has caused an e-mail loop. By default, after 20 iterations of an e-mail loop, Exchange interrupts the loop and generates an NDR to the sender of the message.

Check that the domain name specified is valid, and that a mail exchanger (MX) record exists.

5.4.6

Routing loop detected

This error occurs when the delivery of a message generates another message in response. That message then generates a third message, and the process is repeated, creating a loop. To help protect against exhausting system resources, Exchange interrupts the mail loop after 20 iterations. Mail loops are typically created because of a configuration error on the sending mail server, the receiving mail server, or both. Check the mailbox rules configuration of the recipient and sender to determine whether automatic message forwarding is enabled. View the SMTP Log or a Netmon trace, and ensure that there is adequate disk storage and virtual memory available.

5.5.2

Send hello first

A generic SMTP error occurs when SMTP commands are sent out of sequence. For example, a server attempts to send an AUTH (authorization) command before identifying itself with an EHLO command. It is possible that this error can also occur when the system disk is full. The combined total of recipients on the To, Cc, and Bcc lines of the message exceeds the total number of recipients allowed in a single message.

5.5.3

Too many recipients

This error occurs when the sender has included too many recipients on the message. The sender must reduce the number of recipient addresses in the message or the maximum number of recipients must be increased to allow the message to be successfully delivered. To configure the maximum number of recipients that can be included in a message, use the RecipientLimits parameter on the Set-Mailbox cmdlet. For more information, see Set-Mailbox. Check the recipient address for nonstandard characters.

5.5.4

Invalid domain name

The message contains either an invalid sender or an incorrect recipient address format. One possible cause is that the recipient address format might contain characters that are not conforming to Internet standards. This message indicates a possible protocol error.

5.5.6

Invalid message content

Check Event Log for possible failures.

5.7.1

Delivery not authorized

The sender of the message is not allowed to send messages to the recipient.

This error occurs when the sender tries to send a message to a recipient but the sender is not authorized to do this. This frequently occurs when a sender tries to send messages to a distribution group that has been configured to accept messages only from members of that distribution group or other authorized

senders. The sender must request permission to send messages to the recipient. On an Exchange 2010 server, the following cmdlets accept the AcceptMessageOnlyFrom and AcceptMessagesOnlyFromDLMembers parameters. These enable you to determine who is authorized to send messages to the recipients that you configure: Set-Mailbox Set-MailUser Set-MailContact Set-DistributionGroup Set-DynamicDistributionGroup This error can also occur if an Exchange 2010 transport rule rejects a message because the message matched conditions that are configured on the transport rule. For more information about transport rules, see Understanding Transport Rules. 5.7.1 Unable to relay The sending e-mail system is not allowed to send a message to an e-mail system where that e-mail system is not the final destination of the message. This error occurs when the sending e-mail system tries to send an anonymous message to a receiving e-mail system, and the receiving e-mail system does not accept messages for the domain or domains specified in one or more of the recipients. The following are the most common reasons for this error: A third party tries to use a receiving e-mail system to send spam, and the receiving e-mail system rejects the attempt. By the nature of spam, the sender's e-mail address may have been forged and the resulting NDR could have been sent to the unsuspecting sender's e-mail address. It is difficult to avoid this situation. A domain name service (DNS) mail exchanger (MX) record for a domain points to a receiving e-mail system where that domain is not accepted. The administrator responsible for the specific domain name must correct the DNS MX record or configure the receiving e-mail system to accept messages sent to that domain, or both. For more information about how to accept messages for a domain, see Managing Accepted and Remote Domains. A sending e-mail system or client that should use the receiving e-mail system to relay messages does not have the correct permissions to do this. For more information about transport permissions, see Understanding Permissions.

5.7.1

Client was not authenticated

The sending e-mail system did not authenticate with the receiving e-mail system. The receiving e-mail system requires authentication before message submission.

This error occurs when the receiving server must be authenticated before message submission, and the sending e-mail system has not authenticated with the receiving e-mail system. The sending e-mail system administrator must configure the sending e-mail system to authenticate with the receiving e-mail system for delivery to be successful. This error can also occur if you try to accept anonymous messages from the Internet by using a Hub Transport server that has not been configured to do this. We recommend that you put an Edge Transport server in a perimeter network between the Hub Transport server and the Internet. For more information, see the following topics: Configure Internet Mail Flow Directly Through a Hub Transport Server Configure Internet Mail Flow Through a Subscribed Edge Transport Server

5.7.3

Not Authorized

The sender prohibited reassignment to the alternate recipient.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Supported Locales for Use with System Messages

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2013-03-22 The following table lists the supported language locales available for use together with the New-SystemMessage and Set-SystemMessage cmdlets.

Language code af am-ET ar as-IN bg bn-BD bn-IN bs-Cyrl-BA bs-Latn-BA ca cs cy-GB da de el en es et eu fa fi fil-PH fr ga-IE gl gu ha-Latn-NG he hi hr hu

Language Afrikaans Amharic (Ethiopia) Arabic Assamese (India) Bulgarian Bengali (Bangladesh) Bengali (India) Bosnian (Cyrillic, Bosnia, and Herzegovina) Bosnian (Latin, Bosnia, and Herzegovina) Catalan Czech Welsh (Great Britain) Danish German Greek English Spanish Estonian Basque Persian Finnish Filipino (Philippines) French Irish (Ireland) Galician Gujarati Hausa (Latin, Nigeria) Hebrew Hindi Croatian Hungarian

hy id ig-NG is it iu-Latn-CA ja ka kk km-KH kn ko kok ky lb-LU lo-LA lt lv mi-NZ mk ml-IN mr ms ms-BN mt-MT ne-NP nl nn-NO no nso-ZA or-IN pa pl ps-AF pt pt-PT qut-GT quz-PE

Armenian Indonesian Igbo (Nigeria) Icelandic Italian Inuktitut (Latin, Canada) Japanese Georgian Kazakh Khmer (Cambodia) Kannada Korean Konkani Kyrgyz Luxembourgish (Luxembourg) Lao (Lao People's Democratic Republic) Lithuanian Latvian Maori (New Zealand) Macedonian Malayalam (India) Marathi Malay Malay (Brunei Darussalam) Maltese (Malta) Nepali (Nepal) Dutch Norwegian (Nynorsk) Norwegian Sesotho sa Leboa (South Africa) Oriya (India) Punjabi Polish Pashto (Afghanistan) Portuguese Portuguese (Portugal) K'iche (Guatemala) Quechua (Peru)

ro ru rw-RW si-LK sk sl sq sr sr-Cyrl-CS sv sw ta te th tn-ZA tr tt uk ur uz vi wo-SN xh-ZA yo-NG zh-Hans zh-Hant zh-HK zu-ZA

Romanian Russian Kinyarwanda (Rwanda) Sinhala (Sri Lanka) Slovak Slovenian Albanian Serbian Serbian (Cyrillic, Serbia) Swedish Kiswahili Tamil Telugu Thai Setswana (South Africa) Turkish Tatar Ukrainian Urdu Uzbek Vietnamese Wolof (Senegal) isiXhosa (South Africa) Yoruba (Nigeria) Chinese (Simplified) Chinese (Traditional) Chinese (Hong Kong) isiZulu (South Africa)

You can use the New-SystemMessage cmdlet to create customized delivery status notification (DSN) and quota messages in various languages. For more information about how to create customized DSNs, see Create a Custom DSN Message. 2010 Microsoft Corporation. All rights reserved.
2013 Microsoft. All rights reserved.

DSN Message Identity

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-11-18 You can identify a customized delivery status notification (DSN) message based on its syntax. The identity is the customized DSN message's GUID or a string that consists of the following values:

Locale This variable specifies the locale of the language that the DSN message is displayed in. For a list of locale codes that you can use with the NewSystemMessage command, see Supported Locales for Use with System Messages. Internal or External This variable specifies whether the DSN message is sent only to senders who are part of the internal Microsoft Exchange Server 2010 organization or also to senders outside the Exchange 2010 organization. You can use the Internal option when you want to include a specific e-mail contact or resolution in DSN messages sent to internal senders, but don't want to expose that information to senders outside your organization. DSN code This variable specifies the DSN code of the customized DSN message. The syntax of the DSN message identity is <Locale>\<Internal or External>\<DSN code>. For each DSN code, you can create more than one customized DSN message, which can target internal senders or external senders, and different locales. For example, the following table shows some of the possible configurations for the DSN code 5.1.2 and the corresponding DSN message identities.

Example DSN configurations and identities

DSN configuration Display DSN messages to internal senders with an English (en) locale Display DSN messages to external senders with an English (en) locale Display DSN messages to internal senders with a Japanese (ja) locale Display DSN messages to external senders with a Japanese (ja) locale 2010 Microsoft Corporation. All rights reserved.
2013 Microsoft. All rights reserved.

DSN identity En\Internal\5.1.2 En\External\5.1.2 Ja\Internal\5.1.2 Ja\External\5.1.2

DSN Message Text

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-11-25 You can include text in a customized delivery status notification (DSN) message in Microsoft Exchange Server 2010, and you can format that text in HTML. You can include any information that you want to display to the recipient of the DSN message. For example, you can include a detailed description of the DSN, contact information for your help desk, and a link to your support department's Web site. Each DSN message can contain a maximum of 512 characters. Because DSN messages can be displayed in HTML, you can embed HTML formatting tags in the DSN text. For example, if you want to make some text in your DSN message bold, enclose the text in <B> and </B> HTML tags. The following table provides some examples of valid HTML tags that can be used in DSN message text.

Valid HTML tags for use in DSN messages

HTML tag <B> </B> <A HREF="url"> </A> <BR> <EM> </EM> <P> </P> Note: By default, Exchange 2010 sends HTML DSN messages, but you can configure whether Exchange 2010 sends HTML DSN messages to internal senders, external senders, or both. To configure this behavior, modify the InternalDsnSendHtml parameter and the ExternalDsnSendHtml parameter with the Set-TransportServer command. If the InternalDsnSendHtml parameter is set to $false, Exchange 2010 suppresses HTML tags in DSN messages sent to internal senders. If the ExternalDsnSendHtml parameter is set to $false, Exchange 2010 suppresses HTML tags in DSN messages sent to external senders. The following characters that Exchange 2010 uses in DSN message text have special meanings: Description Bold begin Bold end Hyperlink begin Hyperlink end Link break Italic begin Italic end Paragraph begin Paragraph end

Greater than sign (>) Less than sign (<) Ampersand (&) Quotation marks (") These characters are used to determine where HTML tags begin and end, and where text that should be displayed to senders starts and stops. If you want to display these characters in your DSN messages, you must use the escape codes in the following table. For example, if you want to display the message "Please contact the Help Desk at <1234>.", you must add "Please contact the Help Desk at &lt;1234&gt;." to the DSN message text.

DSN message character escape codes

Escape code &lt; &gt; &quot; &amp; Important: If you include an HTML tag in your DSN message text that contains quotation marks ("), such as <A HREF="url">, you must use single quotation marks (') around the whole DSN message text. You will receive an error message if you use double quotation marks around the whole DSN message text and around an HTML tag. 2010 Microsoft Corporation. All rights reserved.
2013 Microsoft. All rights reserved.

Character < > " &

Understanding DNS Query Failure Sensitivity

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-11-23 You can adjust the DNS query sensitivity for slightly faster message delivery when DNS errors are encountered for the destination domain. However, depending on the DNS errors, this adjustment may cause delivery failures in certain circumstances.

DNS Queries and Remote Message Delivery

In a typical Microsoft Exchange Server 2010 organization, an Edge Transport server that's subscribed to the organization is responsible for delivering messages to external recipients. This Edge Transport server is responsible for accepting the outgoing messages from the Hub Transport server in the organization. The subscribed Edge Transport server must be able to find a destination messaging server that accepts mail for the external recipients. Depending on the destination, the messages are put in one or more remote delivery queues as they await delivery to the remote recipients. For more information about delivery queues, see Understanding Transport Queues. The Edge Transport server queries the configured external DNS servers to find the DNS records that are required to deliver the message. The DNS servers that are configured for external DNS lookups are queried in the order in which they're listed. If one of the DNS servers is unavailable, the query goes to the next DNS server on the list. The DNS servers are queried for the following information:

Mail exchange (MX) records for the domain part of the external recipient The MX record contains the fully qualified domain name (FQDN) of the messaging server that's responsible for accepting messages for the domain, and a preference value for that messaging server. A lower preference value indicates a preferred messaging server. The preference value is important if the domain has more than one MX record. To optimize fault tolerance, most organizations use multiple messaging servers and multiple MX records that have different preference values. Address (A) records for the destination messaging servers Every messaging server that's used in an MX record should have a corresponding A record. The A record is used to find the IP address of the destination messaging server. The subscribed Edge Transport server uses the IP address to open an SMTP connection with the destination messaging server. Although it's technically possible to use the FQDN of a canonical name (CNAME) record in an MX record, this practice violates RFC 974, RFC 1034, RFC 1912, and RFC 2181, and is therefore not supported by most messaging servers. The required combination of iterative DNS queries and recursive DNS queries that start with a root DNS server is used to resolve the FQDN of the messaging server that's found in the MX record into an IP address. In Exchange 2010, there's a DNS query limit that's not configurable of 5 seconds for each DNS server, and a one-minute limit for the entire DNS query.

Potential DNS Problems

Even when the external DNS settings on the Microsoft Exchange Transport server are configured correctly, problems with the DNS records for a specific domain or problems with any of the DNS servers that are used to find the authoritative DNS server for a specific domain may still occur. Generally, these problems are beyond your control and need to be resolved by the parties that own those DNS servers. These DNS-related errors may be caused by one or more of the following conditions:

Invalid DNS records for the destination domain Problems with DNS server utilization Problems with DNS server replication In Exchange 2010, when a DNS query results in errors, the query continues to the next DNS server only if that DNS server hasn't already returned an error for the current query. Exchange 2010 also includes a parameter in the EdgeTransport.exe.config application configuration file that's named DnsFaultTolerance. This parameter has the following values:

Lenient When the DNS query encounters a combination of valid MX records and invalid MX records, the DNS query continues until the DNS query time-out value of one minute is reached. The invalid MX records are discarded, and the valid MX record that has the lowest preference value is used to deliver the message to the destination messaging server. Normal When the DNS query first encounters an invalid MX record, any resolved MX records that have a preference value that's greater than or equal to the invalid MX records are immediately discarded. The remaining MX record that has the lowest preference value is used to deliver the message to the destination messaging server without waiting for the whole DNS query to time out. Although this behavior may result in faster message delivery, the potential drawback of this behavior is the DNS query may have no valid MX records if the following conditions are true: The invalid MX record is the first MX record for the destination domain. The valid MX records have the same precedence value as the invalid MX records. The default value of the DnsFaultTolerance parameter on a Hub Transport server or Edge Transport server in Exchange 2010 is Lenient. In both Normal mode and Lenient mode, the results of the DNS query for an invalid MX record are never cached. The next time that a DNS query is executed, it will try to resolve the MX records for the destination domain. For more information about the EdgeTransport.exe.config file, see Understanding the EdgeTransport.exe.Config File.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Domain Security

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 Domain Security refers to the set of functionality in Microsoft Exchange Server 2010 and Microsoft Office Outlook 2007 that provides a relatively low-cost alternative to S/MIME or other message-level security solutions. The purpose of the Domain Security feature set is to provide administrators a way to manage secured message paths over the Internet with business partners. After these secured message paths are configured, messages that have successfully traveled over the secured path from an authenticated sender are displayed to users as Domain Secured in the Outlook and Microsoft Office Outlook Web App interface. Domain Security uses mutual Transport Layer Security (TLS) authentication to provide session-based authentication and encryption. Mutual TLS authentication differs from TLS as it's usually implemented. Typically, when TLS is implemented, the client verifies that the connection securely connects to the intended server by validating the server's certificate. This is received as part of TLS negotiation. In this scenario, the client authenticates the server before the client transmits data. However, the server doesn't authenticate the session with the client. With mutual TLS authentication, each server verifies the connection with the other server by validating a certificate that's provided by that other server. In this scenario, where messages are received from external domains over verified connections in an Exchange 2010 environment, Outlook 2007 displays a Domain Secured icon. Important: It's beyond the scope of this topic to provide a detailed explanation of cryptography and certificate technologies and concepts. Before you deploy any security solution that uses cryptography and digital certificates, we recommend that you understand the basic concepts of trust, authentication, encryption, and public and private key exchange as they relate to cryptography. For more information, see the references listed at the end of this topic. Looking for management tasks related to managing transport servers? See Managing Transport Servers.

Validation of TLS Certificates

To understand the overall security and resulting trustworthiness of any mutual TLS transmission, you must understand how the underlying TLS certificate is validated. Exchange 2010 includes a set of cmdlets to create, request, and manage TLS certificates. By default, these certificates are self-signed. A self-signed certificate is a certificate that's signed by its own creator. In Exchange 2010, the self-signed certificate is created by the computer running Microsoft Exchange by using the underlying Microsoft Windows Cryptography API (CAPI). Because the certificates are self-signed, the resulting certificates are less trustworthy than certificates that are generated by public key infrastructure (PKI) or a third-party certification authority (CA). Therefore, we recommend that you use self-signed certificates for internal mail only. Alternatively, if the receiving organizations with which you exchange domain-secured e-mail manually add your self-signed certificate to the trusted root certificate store in each of their inbound Edge Transport servers, the self-signed certificates are trusted explicitly. For connections that traverse the Internet, it's a best practice to generate TLS certificates with a PKI or third-party CA. Generating TLS keys with a trusted PKI or thirdparty CA reduces the overall management of Domain Security. For more information about the options regarding trusted certificates and Domain Security, see Using PKI on the Edge Transport Server for Domain Security. You can use the Exchange 2010 certificate cmdlets to generate certificate requests for your own PKI or for third-party CAs. For more information, see Understanding TLS Certificates. For more information about how to configure Domain Security, see the following:

Using Domain Security: Configuring Mutual TLS Domain Security White Paper

Using Exchange Hosted Services

Message-level security is enhanced by or is also available as a service from Microsoft Exchange Hosted Services. Exchange Hosted Services is a set of four distinct hosted services:

Hosted Filtering, which helps organizations protect themselves from e-mail-borne malware Hosted Archive, which helps them satisfy retention requirements for compliance Hosted Encryption, which helps them encrypt data to preserve confidentiality Hosted Continuity, which helps them preserve access to e-mail during and after emergency situations These services integrate with any on-premises Exchange servers that are managed in-house or Hosted Exchange e-mail services that are offered through service providers. For more information about Exchange Hosted Services, see Microsoft Exchange Hosted Services.

Resources
Housley, Russ and Tim Polk. Planning for PKI: Best Practices Guide for Deploying Public Key Infrastructure. New York: John Wiley & Son, Inc., 2001. Adams, Carlisle and Steve Lloyd. Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2nd Edition. New York: John Wiley & Son, Inc., 1996. Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure

2010 Microsoft Corporation. All rights reserved.

 2013 Microsoft. All rights reserved.

Using Domain Security: Configuring Mutual TLS

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-12-07 This topic explains how to configure mutual Transport Layer Security (TLS) for Domain Security, the set of functionality in Microsoft Exchange Server 2010 and Microsoft Office Outlook 2007 that provides a relatively low-cost alternative to S/MIME and other message-level security solutions. For the purposes of this scenario, this topic explains how Exchange administrators at a fictitious company, Contoso, configure their Exchange 2010 environment to exchange domain-secured e-mail with their partner, Woodgrove Bank. Contoso administrators want to make sure that all e-mail sent to and received from Woodgrove Bank is protected with mutual TLS. Also, they want to configure Domain Security functionality so that all mail to and from Woodgrove Bank is rejected if mutual TLS can't be used. Contoso has an internal public key infrastructure (PKI) that generates certificates. The PKI's root certificate has been signed by a major third-party certification authority (CA). Woodgrove Bank uses the same third-party CA to generate their certificates. Therefore, both Contoso and Woodgrove Bank trust the other's root CAs. To set up mutual TLS, Exchange administrators at Contoso perform the following procedures: Step 1: Generate a certificate request for TLS certificates Step 2: Import certificates to Edge Transport servers Step 3: Configure outbound Domain Security Step 4: Configure inbound Domain Security Step 5: Test domain-secured mail flow

Prerequisites

This topic assumes that you have read and understood Generate Request for Third-Party Certificate Services. The Microsoft Exchange EdgeSync service must be fully deployed for Domain Security. Generally, configuration changes that are made to Domain Security functionality that don't use the ExchangeCertificate cmdlets are made within the organization and synchronized to Edge Transport servers by using the Microsoft Exchange EdgeSync service. Before you can successfully run mutual TLS on an Edge Transport server, you must configure the computer and PKI environment so that certificate validation and certificate revocation list checking are operable. For more information, see Using PKI on the Edge Transport Server for Domain Security. Even though individual configuration steps within this scenario can be accomplished with lesser rights, to complete the entire end-to-end scenario tasks, your account needs to be a member of the Organization Management management role group.

Step 1: Generate a Certificate Request for TLS Certificates

Contoso has an internal PKI that's subordinated to a third-party CA. In this scenario, subordination refers to the fact that the CA that's deployed by Contoso in the corporate infrastructure contains a root certificate that has been signed by a public third-party CA. By default, the public third-party CA is one of the trusted root certificates in the Microsoft Windows certificate store. Therefore, any client that includes the same third-party CA in its trusted root store and that connects to Contoso can authenticate to the certificate that's presented by Contoso. Contoso has two Edge Transport servers that require TLS certificates: mail1.contoso.com and mail2.mail.contoso.com. Therefore, the Contoso e-mail administrator must generate two certificate requests, one certificate request for each server. The following example shows the commands that the administrator uses to generate the base64-encoded PKCS#10 certificate requests. The Contoso administrator must run this command for CN=mail1.contoso.com.

$Data1 = New-ExchangeCertificate -GenerateRequest -FriendlyName "Internet certificate for mail1" -SubjectName "DC=com,DC=Contoso,CN=mail1.contoso.com Set-Content -Path "C:\Certificates\mail1-request.req" -Value $Data1

The Contoso administrator must run this command for CN=mail2.mail.contoso.com.

$Data2 = New-ExchangeCertificate -GenerateRequest -FriendlyName "Internet certificate for mail2" -SubjectName "DC=com,DC=Contoso,CN=mail2.mail.contos Set-Content -Path "C:\Certificates\mail2-request.req" -Value $Data2

For detailed syntax and parameter information, see New-ExchangeCertificate. Important: The specific details of the certificate or certificate request that you create depends on many variables. If you're generating a request, make sure that you work closely

with the CA or the PKI administrator who will issue your certificate. For more information about how to create a certificate request for TLS, see Generate Request for Third-Party Certificate Services. Return to top

Step 2: Import Certificates to Edge Transport Servers

After the Contoso administrator generates the certificate requests, the CA administrator for Contoso then uses the requests to generate the certificates for the servers. The resulting certificates must be issued as either a single certificate or a certificate chain and copied to the appropriate Edge Transport servers. Important: Do not use the Certificate Manager snap-in in the Microsoft Management Console (MMC) to import the certificates for TLS on the Exchange server. Using the Certificate Manager snap-in to import certificates on Exchange servers doesn't bind the request that's created in this procedure to the issued certificate. Therefore TLS might fail. You can use the Certificate Manager snap-in to import certificates and keys that are stored as .pfx files into the local computer store. When you import the certificate to the Edge Transport server, you must also enable the certificate for the SMTP service. The Contoso administrator runs the following command on each Edge Transport server, one time for each respective certificate.

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path C:\Certificates\mail1-certificate.pfx -Encoding Byte -ReadCount 0)) | Enable-Exchan

The preceding example imports and enables the TLS certificate by pipelining the certificate to the Enable-ExchangeCertificate cmdlet. You can also enable the certificate after you import it. If you do, you will need to specify the thumbprint of the certificate that you want to enable. For detailed syntax and parameter information, see the Import-ExchangeCertificate and Enable-ExchangeCertificate topics.

Transporting Certificates and Related Keys

When you receive a certificate from your PKI or CA provider, convert the issued certificate to a .pfx (PKCS#12) file so that you can back it up as part of a disaster contingency. A .pfx file contains the certificate and related keys. In some cases, you may want to transport the certificate and keys to move them to other computers. For example, if you have multiple Edge Transport servers where you expect to send and receive e-mail that's domain secured, you can create a single certificate that will work for all servers. In this case, you must have the certificate imported and enabled for TLS on each Edge Transport server. As long as you keep a copy of the .pfx file securely archived, you can always import and enable the certificate. The .pfx file contains the private key so it's important to physically protect the file by keeping it on storage media in a secure location. It's important to understand that the Import-ExchangeCertificate cmdlet always marks the imported private key from the .pfx file as non-exportable. This functionality is by design. When you use the Certificate Manager snap-in in MMC to import a .pfx file, you can specify private key exportability and strong-key protection. Important: Do not enable strong-key protection on certificates that are intended for TLS. Strong-key protection prompts the user every time that the private key is accessed. With Domain Security, the user is the SMTP service on the Edge Transport server. Return to top

Step 3: Configure Outbound Domain Security

You must perform three steps to configure outbound Domain Security:

1. Run the Set-TransportConfig cmdlet to specify the domain with which you want to send domain-secured e-mail. 2. Run the Set-SendConnector cmdlet to set the DomainSecureEnabled property on the Send connector that will send mail to the domain with which you want to send domain-secured e-mail. 3. Run the Get-SendConnector cmdlet to verify the following: The Send connector that will send mail to the domain with which you want to send domain-secured e-mail routes mail with Domain Name System (DNS). The FQDN is set to match either the Subject Name or the Subject Alternative Name of certificates that you're using for Domain Security. Because the changes that you make in these three steps are global, you must make the changes on an internal Exchange server. The configuration changes that you make will be replicated to the Edge Transport servers by using the Microsoft Exchange EdgeSync service.

Step 3a: Specify the Sender Domain in Transport Configuration

It's relatively straightforward to specify the domain with which you want to send domain-secured e-mail. The Contoso administrator runs the following command on an internal Exchange 2010 server.

Set-TransportConfig -TLSSendDomainSecureList woodgrovebank.com

The TLSSendDomainSecureList parameter takes a multivalued list of domain names. The Set-TransportConfig command replaces the whole value for TLSSendDomainSecureList with the new value that's supplied in the cmdlet. Therefore, if you have other domains already configured and want to add a new domain, you need to either include the existing domain in the list or use a temporary variable. The following example shows how to add the woodgrovebank.com domain to

the TLSSendDomainSecureList parameter without overwriting any existing values.

$TransportConfig = Get-TransportConfig $TransportConfig.TLSSendDomainSecureList += "woodgrovebank.com" Set-TransportConfig -TLSSendDomainSecureList $TransportConfig.TLSSendDomainSecureList

For detailed syntax and parameter information, see Set-TransportConfig.

Step 3b: Configure the Default Send Connector

Contoso will use the default DNS-routed Send connector named Internet to send domain-secured e-mail to their partners. Because their default DNS-routed Send connector is a default Internet Send connector, it uses DNS to route mail and doesn't use a smart host. The FQDN is already set to mail.contoso.com. Because the certificates that the Contoso administrator created set the DomainName parameter of the New-ExchangeCertificate to mail.contoso.com, the Send connector can use the certificates without additional configuration. If you've configured a subdomain for testing, you may have to update the FQDN of your Send connector to match the certificate that you've created (for example, subdomain.mail.contoso.com). On the other hand, if you've created a certificate that contains the subdomain in the Subject or Subject Alternative name fields, you don't have to update the FQDN of the Send connector. Therefore, the only configuration that the Contoso administrator must make to the Send connector is to set the DomainSecureEnabled parameter. To do this, the Contoso administrator runs the following command on an internal Exchange 2010 server for the Internet Send connector.

Set-SendConnector Internet -DomainSecureEnabled:$true

For detailed syntax and parameter information, see Set-SendConnector.

Step 3c: Verify the Send Connector Configuration

After completing the configuration changes, the Contoso administrator needs to verify that the Send connector being used for Domain Security is configured correctly. To do so, the Contoso administrator needs to run the following command.

Get-SendConnector Internet | Format-List Name,DNSRoutingEnabled,FQDN,DomainSecureEnabled

This command will list the relevant parameters configured for Domain Security, allowing the Contoso administrator to verify the configuration. For detailed syntax and parameter information, see Get-SendConnector. Return to top

Step 4: Configure Inbound Domain Security

You must perform two steps to enable inbound Domain Security:

1. Run the Set-TransportConfig cmdlet to specify the domain from which you want to receive domain-secured e-mail. 2. On the Edge Transport server, use the Exchange Management Shell or the Exchange Management Console (EMC) to enable Domain Security on the Receive connector from which you want to receive domain-secured e-mail. Because Domain Security requires mutual TLS authentication, TLS must also be enabled on the Receive connector.

Step 4a: Specify the Recipient Domain in Transport Configuration

It's relatively straightforward to specify the domain with which you want to receive domain-secured e-mail. To specify the domain, the Contoso administrator runs the following command in the Shell on an internal Exchange 2010 server or management workstation.

Set-TransportConfig -TLSReceiveDomainSecureList woodgrovebank.com

The TLSReceiveDomainSecureList parameter takes a multivalued list of domain names. The Set-TransportConfig command replaces the whole value for TLSReceiveDomainSecureList parameter with the new value supplied by the Set-TransportConfig cmdlet. Therefore, if you have other domains already configured and want to add a new domain, you need to either include the existing domain in the list or use a temporary variable. The following example shows how to add the woodgrovebank.com domain to the TLSReceiveDomainSecureList parameter without overwriting any existing values.

$TransportConfig = Get-TransportConfig $TransportConfig.TLSReceiveDomainSecureList += "woodgrovebank.com" Set-TransportConfig -TLSReceiveDomainSecureList $TransportConfig.TLSReceiveDomainSecureList

For detailed syntax and parameter information, see Set-TransportConfig.

Step 4b: Configure the Receive Connector

You must configure the Receive connector on each Edge Transport server that accepts mail from the domain from which you want to receive domain-secured e-mail. The Contoso environment is configured to have a single Internet Receive connector, with an Identity parameter value of Internet, on both Edge Transport servers. Therefore, to enable TLS while mail is sent to or received from Woodgrove Bank, the Contoso administrator must make sure that TLS is enabled on the default Internet Receive connector on both Edge Transport servers. To do so, the Contoso administrator runs the following command on both mail1.contoso.com and mail2.mail.contoso.com.

Set-ReceiveConnector Internet -DomainSecureEnabled $true -AuthMechanism TLS

For detailed syntax and parameter information, see Set-ReceiveConnector. You can also use the EMC to configure the Receive connector using the following steps.

1. On the Edge Transport server, open the EMC, click Edge Transport, and then in the result pane, click the Receive Connectors tab. 2. Select the Receive connector that accepts mail from the domain from which you want to receive domain-secured e-mail, the connector Internet in this case, and then click Properties in the action pane. 3. On the Authentication tab, select Transport Layer Security (TLS) and Enable Domain Security (Mutual Auth TLS), and then click OK. Be aware that specifying the authentication mechanism as TLS doesn't force TLS on all inbound connections. TLS will be forced for connections from Woodgrove Bank for the following reasons:

Woodgrove Bank is specified in the Set-TransportConfig cmdlet on the TLSReceiveDomainSecureList parameter. The DomainSecureEnabled parameter is set to $true on the Receive connector. Other senders that aren't listed on the TLSReceiveDomainSecureList parameter in the Set-TransportConfig cmdlet will only use TLS if TLS is supported by the sending system. Return to top

Step 5: Testing Domain-Secured Mail Flow

After you've configured domain-secured e-mail, you can test the connection by reviewing the performance logs and the protocol logs. Messages that have successfully authenticated over the domain-secured mail flow path are displayed in Outlook as Domain Secure messages.

Performance Counters
The Domain Security feature includes the following set of performance counters under MSExchange Secure Mail Transport:

Domain-Secured Messages Received Domain-Secured Messages Sent Domain-Secured Outbound Session Failures You can create a new counter log file for domain-secured mail flow with these performance counters to monitor the number of messages sent and received and also to monitor failed mutual TLS sessions. For more information about how to create and configure counter logs, see the Help file that's included with the Performance Logs and Alerts MMC snap-in.

Protocol Logs
You can review the send and receive protocol logs to determine whether TLS negotiation has been successful. To view detailed protocol logs, you must set the protocol logging level to Verbose on the connectors that your organization uses to send and receive domain secured e-mail. To accomplish this, the Contoso administrator runs the following on both Edge Transport servers.

Set-ReceiveConnector Internet -ProtocolLoggingLevel Verbose

To enable protocol logging on the Send connector, the Contoso administrator runs the following on an internal Exchange server or management workstation. The configuration change is then replicated to the Edge Transport servers using the Microsoft Exchange EdgeSync service.

Set-SendConnector Internet -ProtocolLoggingLevel Verbose

For detailed syntax and parameter information, see the Set-ReceiveConnector and Set-SendConnector topics. For more information about how to view protocol logs, see Configure Protocol Logging.

Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Using PKI on the Edge Transport Server for Domain Security

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 Domain Security relies on mutual Transport Layer Security (TLS) for authentication. Successful mutual TLS authentication relies on a trusted, validated X.509 certificate chain for the TLS certificates that are used for Domain Security. Therefore, before you can successfully deploy Domain Security, you must configure your Edge Transport server and your X.509 public key infrastructure (PKI) to accommodate certificate trusting and certificate validation. Important: It's beyond the scope of this topic to provide a detailed explanation of cryptography and certificate technologies and concepts. Before you deploy any security solution that uses cryptography and X.509 certificates, we recommend that you understand the basic concepts of trust, authentication, encryption, and public and private key exchange as they relate to cryptography. For more information, see the references listed at the end of this topic.

Configuring Root Certification Authorities

To validate a given X.509 certificate, you must trust the root certification authority (CA) that issued the certificate. A root CA is the most trusted CA, which is at the top of a CA hierarchy. The root CA has a self-signed certificate. When you run an application that relies on certificate authentication, each certificate must have a certificate chain that ends in a certificate in the trusted root container of the local computer. The trusted root container contains certificates from root certification authorities. To successfully send domain-secured e-mail, you must be able to validate the receiving server's X.509 certificate. Similarly, when someone sends domain-secured e-mail to your organization, the sending server must be able to validate your certificate. There are two types of trusted root CAs that you can use to implement Domain Security: Built-in third-party root CAs and private root CAs.

Third-Party Root Certification Authorities

Microsoft Windows includes a set of built-in third-party root CAs. If you trust the certificates issued by these third-party root CAs, this means you can verify certificates issued by these CAs. If your organization and your partner organizations are using the default Windows installation and trust the built-in third-party root CAs, trust is automatic. In this scenario, additional trust configuration is not required.

Private Trusted Root Certification Authorities

A private trusted root CA is a root CA that has been deployed by a private or internal PKI. For example, when your organization or the organization that you exchange domain-secured e-mail with has deployed an internal PKI with its own root certificate, you must make additional trust configurations. When private root CAs are used, you must update the Windows trusted root certificate store on the Edge Transport server for Domain Security to function correctly. You can configure trust in two ways: direct root trust and cross-certification. You must understand that whenever the transport service picks a certificate, it validates the certificate before it uses it. Therefore, if you're using a private root CA to issue your certificates, you must include the private root CA in the trusted root certificate store on each Edge Transport server that sends or receives domain-secured e-mail.

Direct Root Trust

If you want to trust a certificate that has been issued by a private root CA, you can manually add that root certificate to the trusted root certificate store on the Edge Transport server computer. For more information about how to manually add certificates to the local certificate store, see the Help file for the Certificate Manager snap-in in Microsoft Management Console (MMC).

Cross-Certification
Cross-certification occurs when one CA signs a certificate that is generated by a different CA. Cross-certification is used to build trust from one PKI with another PKI. In the context of Domain Security, if you have your own PKI, instead of using direct manual trust for a root authority of a partner with an internal PKI, you might create a cross-certificate for the partner CA under your root authority. In this case, trust is established because the cross-certificate ultimately chains back to your trusted root. You must understand that if you have an internal PKI and are using cross-certification, you must manually update the root certificate store on each Edge Transport server that receives domain-secured e-mail so that each Edge Transport server can validate certificates when they receive e-mail from partners that are trusted through cross-certificates. For more information about how to manually add certificates to the local certificate store, see the Help file for the Certificate Manager snap-in in MMC.

Configuring Access to the Certificate Revocation List

Whenever the Transport service retrieves a certificate, it validates the certificate chain and validates the certificate. Validation of the certificate is a process in which many

attributes of the certificate are confirmed. Most of these attributes can be confirmed on the local computer by the application that requests the certificate. For example, the intended use of the certificate, the expiration dates on the certificate, and similar attributes are verifiable outside the context of a PKI. However, verification that the certificate has not been revoked must be validated with the CA that issued the certificate. Therefore, most CAs make a certificate revocation list (CRL) available to the public to validate the revocation status. To successfully use Domain Security, CRLs for CAs that you use or are used by your partners must be available to the Edge Transport servers that send and receive domain-secured e-mail. If the revocation check fails, the receiving Exchange server issues a temporary protocol rejection of the message. A transient revocation failure can occur. For example, the Web server that is used to publish the CRL can fail. Or, general network connectivity issues between the Edge Transport server and the CRL distribution point could fail the revocation check. Therefore, transient revocation failures only cause temporary mail delivery delays because the sending server will retry later. However, CRL validation is required for successful domain-secured e-mail transmission. You must enable the following scenarios:

Your Edge Transport servers must be able to access CRLs for external CAs Each partner with which you exchange domain-secured e-mail must have publicly available CRLs that your organization's Edge Transport server can contact. In some cases, CRLs are only available with Lightweight Directory Access Protocol (LDAP). In most cases, with public CAs, CRLs are published via HTTP. Make sure that the appropriate outbound ports and proxies are configured to let the Edge Transport server contact the CRL. You can determine which protocol a given CRL distribution point accepts by opening a certificate in MMC and viewing the CRL Distribution Points field. You must make the CRL for the CA that issues your certificates publicly available You must understand that even when an Edge Transport server retrieves a certificate from your own organization, it validates the certificate chain to validate the certificate. Therefore, the CRL for your CA must be available to your own Edge Transport servers. In addition, all partners that you exchange domain-secured e-mail with must be able to access the CRL for the CA that issues your certificates.

Configuring Proxy Settings for WinHTTP

Exchange 2010 transport servers rely on the underlying Microsoft Windows HTTP Services (WinHTTP) to manage all HTTP and HTTPS traffic. Both Hub Transport servers and Edge Transport servers may use HTTP to access updates for Microsoft Exchange 2010 Standard Anti-spam Filter Updates and for CRL validation. For more information, see Configure Proxy Settings for WinHTTP.

Testing the PKI and Proxy Configuration

To verify your PKI and proxy configuration for a specific Edge Transport server, use Certutil.exe to verify the certificate chain for your Edge Transport server certificate. Certutil.exe is a command-line tool that is installed as part of Certificate Services in Windows Server 2008 operating systems. For more information, see Test PKI and Proxy Configuration.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Test PKI and Proxy Configuration

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 To verify your public key infrastructure (PKI) and proxy configuration for a specific Edge Transport server, use Certutil.exe to verify the certificate chain for your Edge Transport server certificate. Certutil.exe is a command-line tool installed as part of Certificate Services in the Windows Server 2008 operating system. For more information, see Certutil. Before you can run Certutil to verify the certificate chain for a specific certificate, the certificate must first be in file (.cer) format. Therefore, you must first export the certificate, but not the private keys, to the DER (.cer) file format. The first procedure in this topic shows you how to add the Certificate Manager snap-in to the Microsoft Management Console (MMC). The second procedure explains how to use the Certificate Manager to export a certificate. The third procedure shows how you can run the Certutil command to verify the certificate chain.

Step 1: Add Certificate Manager to the Microsoft Management Console

To perform this procedure, the account you use must be delegated membership in the local Administrators group.

1. 2. 3. 4. 5. 6. 7.

Click Start, click Run, type mmc, and then click OK. On the File menu, click Add/Remove Snap-in. In the Add/Remove Snap-in box, click Add. In the Available Snap-ins list, click Certificates, and then click Add. Click Computer Account, and then click Next. Click the Local computer (the computer this console is running on) option, and then click Finish. Click OK.

Step 2: Export the certificate

To perform this procedure, the account you use must be delegated membership in the local Administrators group.

1. 2. 3. 4. 5. 6. 7. 8.

Open the Certificate Manager that you created in Step 1. Expand the Certificates (Local Computer) folder and the Personal folder, and then click the Certificates folder. In the details pane, right-click the certificate that you will use for Domain Security, click All Task, and then select Export. The Certificate Export Wizard will open. On the Welcome page, click Next. On the Export Private Key page, select No, do not export the private key, and then click Next. On the Export File Format page, select DER encoded binary X.509 (.CER), and then click Next. On the File to Export page, enter the path and file name where you want to save the exported certificate, and then click Next. On the Finish page, verify the settings and then click Finish.

Step 3: Verify the certificate chain for the certificate

To perform this procedure, the account you use must be delegated membership in the local Administrators group. On the Edge Transport server, open a Command Prompt window, and type the following command.

Certutil -verify c:\CertificateName.cer

In this example, CertificateName is the Edge Transport server certificate that you exported in the previous procedure.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Edge Subscriptions

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-02-01 This topic provides detailed information about Edge Subscriptions and the EdgeSync synchronization process. Edge Subscriptions are used to populate the Active Directory Lightweight Directory Services (AD LDS) instance on the Microsoft Exchange Server 2010 Edge Transport server role with Active Directory data. In Exchange 2010, the Edge Transport server role is deployed in your organization's perimeter network. Designed to minimize the attack surface, the Edge Transport server handles all Internet-facing mail flow and provides SMTP relay and smart host services for the Exchange organization. Additional layers of message protection and security are provided by a series of agents that run on the Edge Transport server and act on messages as they're processed by the message transport components. These agents support the features that provide protection against viruses and spam and apply transport rules to control message flow. Although creating an Edge Subscription is optional, subscribing an Edge Transport server to the Exchange organization provides a simpler management experience for the administrator and enhances the available anti-spam features. You must create an Edge Subscription if you plan to use recipient lookup or safelist aggregation, or if you plan to help secure SMTP communications with partner domains by using mutual Transport Layer Security (TLS). Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents Edge Subscription Process Microsoft Exchange EdgeSync Service Managing Edge Subscriptions

Edge Subscription Process

In a typical deployment scenario, the computer that has the Edge Transport server role installed doesn't have access to Active Directory. All the configuration and recipient information that the Edge Transport server has to process messages is stored in AD LDS. Creating an Edge Subscription establishes secure, automatic replication of information from Active Directory to AD LDS. The Edge Subscription process provisions the credentials that are used to establish a secure LDAP connection between Hub Transport servers and a subscribed Edge Transport server. The Microsoft Exchange EdgeSync service that runs on Hub Transport servers then performs periodic one-way synchronization to transfer data to AD LDS and keep that data up to date. This process reduces the administration that you must perform in the perimeter network by letting you perform required configuration on the Hub Transport server role and then write that information to the Edge Transport server. You subscribe an Edge Transport server to the Active Directory site that contains the Hub Transport servers that will directly exchange messages with your Edge Transport servers. The Edge Subscription process creates an Active Directory site membership affiliation for the Edge Transport server. The site affiliation enables Hub Transport servers in the Exchange organization to relay messages to the Edge Transport server for delivery to the Internet without having to configure explicit Send connectors. One or more Edge Transport servers can be subscribed to a single Active Directory site. However, an Edge Transport server can't be subscribed to more than one Active Directory site. If you have more than one Edge Transport server deployed, each server can be subscribed to a different Active Directory site. Each Edge Transport server requires an individual Edge Subscription. To deploy an Edge Transport server and subscribe it to an Active Directory site, follow these steps:

1. 2. 3. 4.

Install the Edge Transport server role. Verify that the Hub Transport servers and the Edge Transport server can locate one another by using Domain Name System (DNS) name resolution. Configure the objects and settings to be replicated to the Edge Transport server. On the Edge Transport server, create and export an Edge Subscription file. For more information about this step, see Create an Edge Subscription File on an Edge Transport Server. 5. Copy the Edge Subscription file to a Hub Transport server or a file share that's accessible from the Active Directory site that has your Hub Transport servers. 6. Import the Edge Subscription file to your Active Directory site to which you want to subscribe your Edge Transport server. For more information about this step, see Import an Edge Subscription File to an Active Directory Site. The following figure illustrates the Edge Subscription process.

Configuration Changes Made When a New Edge Subscription Is Created

When you run the New-EdgeSubscription cmdlet on the Edge Transport server to create an Edge Subscription file, the following actions occur:

An AD LDS account is created. This account is called the EdgeSync bootstrap replication account (ESBRA). These credentials are used to authenticate the first EdgeSync connection to the Edge Transport server. The account is configured to expire 1,440 minutes (24 hours) after it's created. Therefore, you must complete the subscription process before that time expires. If the ESBRA expires before the Edge Subscription process is complete, you must run the NewEdgeSubscription cmdlet on the Edge Transport server again to create an Edge Subscription file. The ESBRA credentials are retrieved from AD LDS and written to the Edge Subscription file. The public key for the Edge Transport server's self-signed certificate is also exported to the Edge Subscription file. The credentials that are written to the Edge Subscription file are specific to the server from which the file is exported. Any previously created configuration objects in a class that will now be replicated to AD LDS from Active Directory are deleted from AD LDS and the Exchange Management Shell commands used to configure those objects are disabled. You can still use the cmdlets that let you view those objects. The following cmdlets are disabled on the Edge Transport server when you run the New-EdgeSubscription cmdlet: Set-SendConnector New-SendConnector Remove-SendConnector New-AcceptedDomain Set-AcceptedDomain Remove-AcceptedDomain New-MessageClassification Set-MessageClassification Remove-MessageClassification New-RemoteDomain Set-RemoteDomain Remove-RemoteDomain When you import the Edge Subscription file on the Hub Transport server by running the New-EdgeSubscription cmdlet in the Shell or by using the New Edge Subscription wizard in the Exchange Management Console, the following actions occur:

The Edge Subscription is created, establishing a record of an Edge Transport server that has been joined to an Exchange organization and to which the Microsoft Exchange EdgeSync service will propagate configuration data. This step creates the edge configuration object in Active Directory. Each Hub Transport server in the Active Directory site receives notification from Active Directory that a new Edge Transport server has been subscribed. The Hub Transport server retrieves the ESBRA from the Edge Subscription file. The Hub Transport server then encrypts the ESBRA by using the public key of the Edge Transport server's self-signed certificate. The encrypted credentials are then written to the edge configuration object. Each Hub Transport server also encrypts the ESBRA by using its own public key and then stores the credentials in its own configuration object. EdgeSync replication accounts (ESRAs) are created in Active Directory for each Edge Transport-Hub Transport server pair. Each Hub Transport server stores its ESRA credentials as an attribute of the Hub Transport server configuration object. Send connectors are automatically created to relay messages outbound from the Edge Transport server to the Internet, and inbound from the Edge Transport server to the Exchange organization. The Microsoft Exchange EdgeSync service that runs on Hub Transport servers uses the ESBRA credentials to establish a secure LDAP connection between a Hub Transport server and the Edge Transport server and performs the initial replication of data. The following data is replicated to AD LDS: Topology data Configuration data Recipient data ESRA credentials The Microsoft Exchange Credential Service that runs on the Edge Transport server installs the ESRA credentials. These credentials are used to authenticate and secure later synchronization connections. The EdgeSync synchronization schedule is established. The Microsoft Exchange EdgeSync service that's running on the Hub Transport servers in the Active Directory site to which the Edge Transport server is subscribed will now perform one-way replication of data from Active Directory to AD LDS on a regular schedule. You can also use the Start-EdgeSynchronization cmdlet in the Shell to override the EdgeSync synchronization schedule and immediately start synchronization. For more information about ESRA accounts and how they're used to help secure the EdgeSync synchronization process, see Understanding Edge Subscription Credentials.

Send Connectors Created During Edge Subscription Process

By default, when you complete the Edge Subscription process by importing the Edge Subscription file to a Hub Transport server, the Send connectors that are required to enable end-to-end mail flow between the Internet and the Exchange organization are created automatically. Any existing Send connectors on the Edge Transport server are deleted. Even though that's the recommended method, you can also select to suppress automatic creation of Send connectors and configure Send connectors manually. For more information about manually configuring Send connectors, see Configure Mail Flow Between an Edge Transport Server and Hub Transport Servers Without Using EdgeSync. The Edge Subscription process provisions the following Send connectors:

A Send connector that's configured to relay e-mail messages from the Exchange organization to the Internet A Send connector that's configured to relay e-mail messages from the Edge Transport server to the Exchange organization Also, by subscribing an Edge Transport server to the Exchange organization, you enable Hub Transport servers that are located in the Active Directory site to which the Edge Transport server is subscribed to use the intra-organization Send connector to relay messages to that Edge Transport server.

Automatically Create a Send Connector to Send Messages to the Internet

By default, when you run the New-EdgeSubscription cmdlet in the Shell on the Hub Transport server, the CreateInternetSendConnector parameter is set to $true. This creates the Send connector that's required to send messages to the Internet. The following table shows the default configuration of this Send connector. Automatic Internet Send connector configuration

Parameter Name

Value EdgeSync - <Site Name> to Internet

Address Space Source Servers

SMTP:*;100 Edge Subscription name Note: The name of the Edge Subscription is the same as the name of the subscribed Edge Transport server.

Enabled DNS Routing Enabled Domain Secure Enabled (Mutual Auth TLS)

True True True

If more than one Edge Transport server is subscribed to the same Active Directory site, additional Send connectors to the Internet aren't created. Instead, all Edge Subscriptions are added to the same Send connector as source servers. This configuration causes outbound connections to the Internet to be load balanced between the subscribed Edge Transport servers. This Send connector is configured to send e-mail messages from the Exchange organization to all remote SMTP domains. It will use DNS routing to resolve domain names to MX resource records. You can modify the configuration of this connector manually. However, if you must route outbound e-mail through a smart host, for example, you can suppress creation of this connector and manually configure a Send connector to the Internet. Note: A Send connector that's configured to use a smart host to route e-mail must have the DNSRoutingEnabled parameter set to $false. If the DNSRoutingEnabled parameter is set to $false, the DomainSecureEnabled parameter must also be set to $false.

Automatically Create an Inbound Send Connector

By default, when you run the New-EdgeSubscription cmdlet in the Shell on the Hub Transport server, the CreateInboundSendConnector is parameter set to $true. This creates the Send connector that's required to send messages to the Exchange organization. The following table shows the configuration of this Send connector. Automatic inbound Send connector configuration

Parameter Name Address Space Source Servers Enabled DNS Routing Enabled Smart Hosts

Value EdgeSync - Inbound to <Site Name> SMTP:--;1 Edge Subscription name True False --

The -- placeholder in the address space for the inbound Send connector represents the authoritative and internal relay accepted domains for the Exchange organization and is the literal character displayed. Any messages that the Edge Transport server receives for authoritative and internal relay accepted domains are routed to this Send connector and relayed to the smart hosts. The -- placeholder in the list of smart hosts represents all the Hub Transport servers that are located in the subscribed Active Directory site and is the literal character displayed. Hub Transport servers that are added to an Active Directory site after an Edge Subscription has been established don't participate in the EdgeSync synchronization process. However, they are automatically added to the list of smart hosts for the inbound Send connector. If more than one Hub Transport server is located in the subscribed Active Directory site, inbound connections will be load balanced across the smart hosts. You can't modify the address space or list of smart hosts for the automatically created inbound Send connector. However, you can set the value of the CreateInboundSendConnector parameter to $false when creating an Edge Subscription, and manually configure a Send connector from the Edge Transport server to the Exchange organization.

Intra-Organization Send Connector

The intra-organization Send connector is an implicit and hidden Send connector that's automatically computed by Exchange 2010 and enables Hub Transport servers in the same organization to relay messages to each other without using explicit Send connectors. Because a configuration object that has an Active Directory site association exists in Active Directory for an Edge Subscription, the intra-organization Send connector will also be used to relay messages to that Edge Transport server. Only Hub Transport servers that are located in the same Active Directory site to which the Edge Transport server is subscribed can send and receive e-mail directly to or from the subscribed Edge Transport server. If you have a multiple site forest and Exchange 2010 is deployed in more than one site, the Hub Transport servers in non-subscribed sites will route outbound e-mail to the subscribed site. A Hub Transport server in the subscribed site will route outbound e-mail to the Edge Transport server.

Creating Additional Send Connectors After Edge Subscription is Completed

After an Edge Transport server is subscribed to an Active Directory site, the tasks for creating and modifying Send connectors are disabled on the Edge Transport server. If you want to create a Send connector for which the Edge Transport server is a source server, you create the Send connector inside the Exchange organization. You can specify one or more Edge Subscriptions as the source server for a Send connector. You can't specify both Hub Transport servers and Edge Subscriptions as source servers for the same Send connector. The Send connector will be replicated to the AD LDS instance on the Edge Transport server that's configured as a source server the next time that configuration data is synchronized by the EdgeSync synchronization process. If you list more than one Edge Subscription as a source server, connections to that Send connector will be load balanced between the subscribed Edge Transport servers. However, the Edge Transport servers have to be subscribed to the same Active Directory site for load balancing to occur. If Edge Subscriptions in different Active Directory sites are configured as source servers on the same Send connector, Hub Transport servers will route only to the closest source server. You have to create Send connectors manually in the following scenarios:

You've suppressed automatic creation of the Internet or inbound Send connectors. You've accepted domains that are configured as external relay domains.

Suppressing Automatic Creation of Send Connectors

Depending on the topology of your Exchange organization, you may decide to suppress automatic creation of Send connectors. The following scenarios provide examples of topologies that require that you suppress automatic creation of Send connectors.

Partitioning Mail Flow

You may decide to partition the inbound and outbound mail processing between two Edge Transport servers. In this scenario, one Edge Transport server is responsible for processing outbound mail flow and a second Edge Transport server is responsible for processing inbound mail flow. To achieve this scenario, you configure the Edge Subscriptions as follows:

For the Edge Transport server that processes only outbound mail flow, run the following command in the Shell on the Hub Transport server.

New-EdgeSubscription -FileData ([byte[]]$(Get-Content -Path "C:\EdgeServerSubscription.xml" -Encoding Byte -ReadCount 0)) -Site "Site-A"

For the Edge Transport server that processes only inbound mail flow, run the following command in the Shell on the Hub Transport server.

New-EdgeSubscription -FileData ([byte[]]$(Get-Content -Path "C:\EdgeServerSubscription.xml" -Encoding Byte -ReadCount 0)) -Site "Site-A"

Routing Outbound E-Mail to a Smart Host

If your Exchange organization routes all outbound e-mail through a smart host, the default automatically created Send connector to the Internet won't have the correct configuration. In this scenario, you run the following command in the Shell on the Hub Transport server to suppress automatic creation of the Send connector to the Internet.

New-EdgeSubscription -FileData ([byte[]]$(Get-Content -Path "C:\EdgeServerSubscription.xml" -Encoding Byte -ReadCount 0)) -Site "Site-A" -Creat

After the Edge Subscription process is complete, manually create a Send connector to the Internet. Create the Send connector inside the Exchange organization and select the Edge Subscription as the source server for the connector. Select the Custom usage and configure one or more smart hosts. The Send connector will be replicated to the AD LDS instance on the Edge Transport server the next time that EdgeSync synchronizes configuration data. You can also force EdgeSync synchronization to immediately start by running the Start-EdgeSynchronization cmdlet in the Shell on a Hub Transport server. The following code provides an example of how to use the Shell to configure a Send connector for a subscribed Edge Transport server to route messages for all Internet address spaces through a smart host. This task is run inside the Exchange organization, not on the Edge Transport server.

New-SendConnector -Name "EdgeSync - Site-A to Internet" -Usage Custom -AddressSpaces SMTP:*;100 -DNSRoutingEnabled $false -SmartHosts 192.168.1

Important: This example doesn't specify any smart host authentication mechanism. Make sure that you configure the correct authentication mechanism and provide all necessary credentials when you create a smart host connector in your own Exchange organization.

Configuring Send Connectors for External Relay Domains

If you've accepted domains in your Exchange organization that are configured as external relay domains, you have to manually create a Send connector for those address spaces. Messages that are being delivered to external relay domains are relayed by the Edge Transport server. The Edge Subscription process doesn't automatically create and configure Send connectors for external relay domains. Therefore, you have to configure Send connectors for those domains and specify one or more Edge Subscriptions as the source server for those Send connectors.

The DNS MX resource record for an external relay domain resolves to your Edge Transport server. Configure a Send connector that relays e-mail to an external relay domain to use a smart host for routing. If you configure the Send connector for an external relay domain to use DNS routing, a routing loop will occur. For more information about external relay domains, see Understanding Accepted Domains. Return to top

Microsoft Exchange EdgeSync Service

After you subscribe an Edge Transport server to an Active Directory site, the EdgeSync service that runs on the Hub Transport servers will replicate configuration and recipient data to the Edge Transport servers using the Microsoft Exchange EdgeSync service. The service replicates the following data from Active Directory to AD LDS:

Send connector configuration Accepted domains Remote domains Message classifications Safe Senders Lists Blocked Senders Lists Recipients List of send and receive domains used in domain secure communications with partners List of SMTP servers listed as internal in your organization's transport configuration List of Hub Transport servers in the subscribed Active Directory site For more information about the data that's replicated to AD LDS and how it's used, see EdgeSync Replication Data. The Microsoft Exchange EdgeSync service uses a secure LDAP channel to transfer this data. A mutually authenticated and authorized secure LDAP channel is established from the Hub Transport server to the Edge Transport server. To replicate data to AD LDS, the Hub Transport server binds to a global catalog server to retrieve updated data. The Microsoft Exchange EdgeSync service initiates a secure LDAP session between a Hub Transport server and the subscribed Edge Transport server over the non-standard TCP port 50636. The following figure illustrates the EdgeSync synchronization process.

When you first subscribe an Edge Transport server to an Active Directory site, the initial replication that populates AD LDS with data from Active Directory can take some time, depending on the quantity of data in the directory service. After the initial replication is complete, the EdgeSync service only synchronizes the new and changed objects and removes any objects that have been deleted from Active Directory.

Synchronization Schedule
Different types of data synchronize on different schedules. The EdgeSync synchronization schedule specifies the maximum length of time between EdgeSync synchronization intervals. EdgeSync synchronization occurs at the following intervals:

Configuration data is scheduled to be synchronized at 3-minute intervals. Recipient data is scheduled to be synchronized at 5-minute intervals. Topology data is reloaded every 5 minutes. You use the Set-EdgeSyncServiceConfig cmdlet to configure the EdgeSync synchronization schedule intervals. If you use the Start-EdgeSynchronization cmdlet in the Shell on the Hub Transport server to force Edge Subscription synchronization to occur immediately, you override the timer that determines the next time that EdgeSync synchronization is scheduled to occur.

Selection of Hub Transport Server

A subscribed Edge Transport server is associated with a particular Active Directory site. If more than one Hub Transport server exists in the site, any of them can replicate data to the subscribed Edge Transport servers. To avoid contention among the Hub Transport servers when synchronizing, the selection of the preferred Hub Transport server occurs as follows:

1. The first Hub Transport server in the Active Directory site to perform a topology scan and discover the new Edge Subscription performs the initial replication. Because this discovery is based on the timing of the topology scan, any Hub Transport server in the site may perform the initial replication. 2. The Hub Transport server that performs the initial replication establishes an EdgeSync lease option and sets a lock on the Edge Subscription. The lease option establishes that Hub Transport server as the preferred server to provide synchronization services to that Edge Transport server. The lock prevents the Microsoft Exchange EdgeSync service on another Hub Transport server from taking over the lease option. 3. The EdgeSync lease option lasts for one hour. No other Microsoft Exchange EdgeSync service can take over the option from another Hub Transport server during this one-hour period unless a manual synchronization occurs before this period expires. If the preferred Hub Transport server isn't available to provide the Microsoft Exchange EdgeSync service when manual synchronization is performed, after a five-minute wait, the lock is released and another Microsoft Exchange EdgeSync service takes over the lease option and performs synchronization. 4. If manual synchronization isn't performed, synchronization occurs based on the EdgeSync synchronization schedule. If the preferred server isn't available when scheduled synchronization occurs, after a five-minute wait, the lock is released and another Microsoft Exchange EdgeSync service takes over the lease option and performs synchronization. This method of locking and leasing prevents more than one instance of the Microsoft Exchange EdgeSync service from pushing data to the same Edge Transport

server at the same time. Note: If you have both Exchange 2010 and Exchange Server 2007 Hub Transport servers in the Active Directory site to which your Edge Transport server is subscribed, Exchange 2010 Hub Transport servers will always take precedence over Exchange 2007 Hub Transport servers. Note: When an Edge Transport server is subscribed to an Active Directory site, all the Hub Transport servers that are installed in that Active Directory site at that time can participate in the EdgeSync synchronization process. If one of those servers is removed, the Microsoft Exchange EdgeSync service that's running on the remaining Hub Transport servers will continue the data synchronization process. However, if new Hub Transport servers are installed in the Active Directory site, they won't participate in the EdgeSync synchronization process automatically. To enable those Hub Transport servers to participate in the EdgeSync synchronization process, you have to subscribe the Edge Transport server again. The following table lists the EdgeSync properties that are related to the locking and leasing process. You can use the Set-EdgeSyncServiceConfig cmdlet to configure these properties. EdgeSync lease properties

Property name Lock duration

Value

Description

5 minutes

This setting determines for how long a particular Microsoft Exchange EdgeSync service will acquire a lock. If the Microsoft Exchange EdgeSync service on the Hub Transport server that's holding this lock doesn't respond, it will take five minutes for the Microsoft Exchange EdgeSync service on another Hub Transport server to take over the lease. Forcing EdgeSync synchronization doesn't override this value. This setting determines for how long a Microsoft Exchange EdgeSync service can declare a lease option on an Edge Transport server. If the Microsoft Exchange EdgeSync service holding the lease is unavailable and doesn't restart during this option period, no other Microsoft Exchange EdgeSync service will take over the lease option, unless you force EdgeSync synchronization. This setting determines how frequently the lock field is updated when a Microsoft Exchange EdgeSync service has acquired a lock to an Edge Transport server.

Option duration

1 hour

Lock renewal

1 minute

Preparing to Run the EdgeSync Service

Before you can subscribe your Edge Transport server to your Exchange organization, you must make sure that your infrastructure and your Hub Transport servers are prepared for the EdgeSync service. The following list summarizes the things you need to do to prepare for EdgeSync synchronization:

Verify that the perimeter network firewall that separates the Edge Transport server from the Exchange organization is configured to enable communications through the correct ports. The Edge Transport server uses non-standard LDAP ports. You can modify the ports that are used by AD LDS by using the ConfigureAdam.ps1 script that's provided with Exchange 2010 if your environment requires specific ports. For more information, see Modify AD LDS Configuration. However, don't modify the ports after you create the Edge Subscription. If you modify the ports after you create the Edge Subscription, you must remove the Edge Subscription and then create a subscription. By default, the following LDAP ports are used to access AD LDS: LDAP Port 50389/TCP is used locally to bind to the AD LDS instance. This port doesn't have to be open on the perimeter network firewall. Secure LDAP Port 50636/TCP is used for directory synchronization from Hub Transport servers to AD LDS. This port must be open for successful EdgeSync synchronization. Verify that DNS host name resolution is successful from the Edge Transport server to the Hub Transport servers, and from the Hub Transport servers to the Edge Transport server. License the Edge Transport server. The licensing information for the Edge Transport server is captured when the Edge Subscription is created and is shown in the EMC for the Exchange organization. For subscribed Edge Transport servers to appear as licensed, they must be subscribed to the Exchange organization after the license key is applied on the Edge Transport server. If the license key is applied on the Edge Transport server after you perform the Edge Subscription process, the licensing information isn't updated in the Exchange organization, and you must resubscribe the Edge Transport server. Configure the following settings for propagation to the Edge Transport server role: Internal SMTP servers Use the Set-TransportConfig cmdlet to configure the InternalSMTPServers parameter. This parameter specifies a list of internal SMTP server IP addresses or IP address ranges that should be ignored by Sender ID and connection filtering. Accepted domains Configure all authoritative domains, internal relay domains, and external relay domains. Remote domains Configure remote domain settings. Return to top

Managing Edge Subscriptions

This section provides background information about various Edge Subscription management tasks. For step-by-step instructions, see Managing Edge Subscriptions.

Adding an Edge Transport Server

You can subscribe one or more Edge Transport servers to a single Active Directory site. If you deploy additional Edge Transport servers in your perimeter network and subscribe them to the same Active Directory site where an Edge Subscription already exists, the following actions occur:

A new Edge Subscription object is created in Active Directory. Additional ESRA accounts are created for each Hub Transport server in the Active Directory site. These accounts are replicated to AD LDS and used by the EdgeSync synchronization process during synchronization with the new server. The new Edge Subscription is added to the source server list of the automatic Send connector to the Internet. Messages submitted to that connector for processing will be load balanced between the subscribed Edge Transport servers. An inbound Send connector from the Edge Transport server to the Exchange organization is automatically created.

EdgeSync synchronization to the Edge Transport server starts. For detailed steps about creating an Edge Subscription, see the following topics:

Create an Edge Subscription File on an Edge Transport Server Import an Edge Subscription File to an Active Directory Site

Adding or Removing a Hub Transport Server

If a Hub Transport server is added to the Active Directory site to which an Edge Transport server is already subscribed, it doesn't automatically participate in the EdgeSync synchronization process. To enable a newly deployed Hub Transport server to participate in the EdgeSync synchronization process, you must resubscribe each Edge Transport server to the Active Directory site. Removing a Hub Transport server from an Active Directory site where an Edge Transport server is subscribed won't affect EdgeSync synchronization, unless that Hub Transport server is the last Hub Transport server in that site. If you remove all Hub Transport servers from the Active Directory site where an Edge Transport server is subscribed, the subscribed Edge Transport servers are orphaned.

Resubscribing an Edge Transport Server

Occasionally you may have to resubscribe an Edge Transport server to an Active Directory site. When the Edge Subscription is re-created, new credentials are generated and the complete Edge Subscription process must be followed. This process is used in the following scenarios:

New Hub Transport servers have been deployed in the subscribed Active Directory site, and you want the new server to participate in EdgeSync synchronization. The license key for the Edge Transport server was applied after the Edge Subscription was created. The licensing information for the Edge Transport server is captured when the Edge Subscription is created and is shown in the EMC for the Exchange organization. For subscribed Edge Transport servers to appear as licensed, they must be subscribed to the Exchange organization after the license key is applied on the Edge Transport server. If the license key is applied on the Edge Transport server after you perform the Edge Subscription process, the licensing information isn't updated in the Exchange organization and you must resubscribe the Edge Transport server. The ESRA credentials are compromised. Important: To resubscribe an Edge Transport server, export a new Edge Subscription file on the Edge Transport server and then import the XML file on a Hub Transport server. You must resubscribe the Edge Transport server to the same Active Directory site to which it was originally subscribed. You don't have to first remove the original Edge Subscription. The resubscription process will overwrite the existing Edge Subscription.

Removing an Edge Subscription

There are some scenarios where you may have to remove an Edge Subscription from the Exchange organization or from both the Exchange organization and the Edge Transport server. If the Edge Transport server will be resubscribed to the Exchange organization, don't remove the Edge Subscription from the Edge Transport server. When you remove the Edge Subscription from an Edge Transport server, all replicated data is deleted from AD LDS. This can take a long time if you have lots of recipient data. The following list provides examples of situations that require you to remove the Edge Subscription.

You no longer want the Edge Transport server to participate in the EdgeSync synchronization process. In this scenario, you must remove the Edge Subscription from both the Edge Transport server and from the Exchange organization. An Edge Transport server is being decommissioned. In this scenario, you must remove the Edge Subscription from the Exchange organization only. If you uninstall the Edge Transport server role from the computer, the AD LDS instance and all Active Directory data that's stored in AD LDS is also removed. You want to change the Active Directory site association for the Edge Subscription. In this scenario, you must remove the Edge Subscription from only the Exchange organization. After the Edge Subscription is removed from the Exchange organization, you can resubscribe the Edge Transport server to a different Active Directory site. When you remove the Edge Subscription from the Exchange organization, the effect is as follows:

Synchronization of information from Active Directory to AD LDS stops. The ESRA accounts are removed from both Active Directory and AD LDS. The computer that has the Edge Transport server role installed is removed from the source server list of any Send connector. The automatic inbound Send connector from the Edge Transport server to the Exchange organization is removed from AD LDS. When you remove the Edge Subscription from an Edge Transport server, the effect is as follows:

You can no longer use the Edge Transport server features that rely on Active Directory data. Replicated data is removed from AD LDS. The tasks that were disabled when the Edge Subscription was created are enabled again to allow for local configuration. For step-by-step instructions about how to remove an Edge Subscription, see Remove an Edge Subscription.

Verifying EdgeSync Results

You can use the Test-EdgeSynchronization diagnostic cmdlet to verify that the edge synchronization is working. This cmdlet provides a report of the synchronization status of subscribed Edge Transport servers. It can be run manually or called by Microsoft System Center Operations Manager 2007. When the task is called by System Center Operations Manager 2007, alerts are generated if an Edge Transport server isn't synchronized.

The output of this cmdlet lets you view which objects haven't been synchronized to the Edge Transport server. The task compares the data that's stored in Active Directory and the data that's stored in AD LDS. Any inconsistencies in data are reported in the results output by this command. You can use the ExcludeRecipientTest parameter with the Test-EdgeSynchronization cmdlet to exclude validation of recipient data synchronization. If you include this parameter, only the synchronization of configuration objects is validated. Validating that recipient data is synchronized will take longer than validating only configuration data. For detailed steps, see Verify EdgeSync Results for a Recipient. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

EdgeSync Replication Data

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 The computer that has the Edge Transport server role installed doesn't have access to Active Directory. To perform recipient lookup and safelist aggregation tasks, and to implement domain security by using mutual Transport Layer Security (TLS) authentication, the Edge Transport server requires data that resides in Active Directory. This data is replicated to the Edge Transport server using the EdgeSync process and the Edge Transport server stores all replicated information in Active Directory Lightweight Directory Services (AD LDS). This topic focuses on the data that's replicated from Active Directory to the AD LDS instance on a Microsoft Exchange Server 2010 Edge Transport server when the Edge Transport server is subscribed to an Active Directory site. To learn more about the EdgeSync process and Edge Subscriptions, see Understanding Edge Subscriptions. The following data are replicated from Active Directory to AD LDS:

Edge Subscription information Configuration information Recipient information Topology information The following sections describe these types of data and the way they're used by the Edge Transport server. Looking for management tasks related to managing transport servers? See Managing Transport Servers.

Edge Subscription Information

Exchange 2010 extends both the Active Directory and AD LDS schemas to provide attributes on the ms-Exch-ExchangeServer object to represent the data needed to control the EdgeSync synchronization process. These attributes provide the following three functions that are important to the EdgeSync synchronization process:

They provide automatic provisioning and maintenance of the credentials that are used to help secure the LDAP connection between a Hub Transport server and a subscribed Edge Transport server. They arbitrate the synchronization lock and lease process that makes sure that only one Hub Transport server at a time will try to synchronize with an individual Edge Transport server. For more information about the lock and lease process, see Understanding Edge Subscriptions. They optimize the EdgeSync synchronization process to maintain a record of the current synchronization status and avoid excessive manual synchronization. The following table lists the schema extensions that are specific to Edge Subscriptions. The values assigned to these attributes are maintained by the Edge Subscription and EdgeSync synchronization process. You shouldn't manually edit these attributes by using editing tools, such as Ldp.exe or Active Directory Service Interfaces (ADSI) Edit.

Edge Subscription schema extensions

Attribute name ms-ExchServerEKPKPublicKey ms-ExchEdgeSyncCredential Description

This attribute represents the current public key for the certificate being used by the server. This value is stored by both Edge Transport servers and Hub Transport servers. The public key is used to encrypt the credentials that are used to authenticate the server during LDAP and SMTP communication.

This attribute represents the list of credentials that the Microsoft Exchange EdgeSync service uses to establish an authenticated LDAP session to AD LDS. On Hub Transport servers, this attribute contains only the credentials that the Hub Transport server uses to authenticate to the subscribed Edge Transport servers. On Edge Transport servers, this attribute contains the credentials of each Hub Transport server in the subscribed Active Directory site that participates in the EdgeSync synchronization process. This attribute is only present on Hub Transport servers that run the EdgeSync synchronization process and on subscribed Edge Transport servers. This attribute is used to arbitrate between Hub Transport servers when more than one Hub Transport server tries to replicate to the same Edge Transport server.

ms-ExchEdgeSyncLease ms-ExchEdgeSyncStatus

This attribute is only present in AD LDS on the Edge Transport server object. This attribute tracks the status of replication to an AD LDS instance and includes information about replication.

Configuration Information
When you subscribe an Edge Transport server to the organization, you can manage the configuration objects that are common to the Edge Transport server and the Exchange organization from inside the organization. These changes are then replicated to the Edge Transport server by using the Microsoft Exchange EdgeSync service. This process helps maintain a consistent configuration across all servers involved in message processing. A subset of the configuration data for the Exchange organization must also be maintained on the Edge Transport server. During the EdgeSync synchronization process, the configuration data that the Edge Transport server needs is written to the configuration partition of AD LDS. The configuration data written to AD LDS includes the

following:

Hub Transport servers The fully qualified domain name (FQDN) of each Hub Transport server in the subscribed Active Directory site is made available to the local AD LDS store on the Edge Transport server. This information is used to derive a list of smart host servers for the inbound Send connector. Accepted domains All authoritative, internal relay, and external relay domains configured for the Exchange organization are written to AD LDS. Having the accepted domains available to the Edge Transport server enables the Exchange organization to perform domain filtering and reject invalid SMTP traffic into their organization as early as possible. For more information about accepted domains, see Understanding Accepted Domains. Message classifications If message classifications are available on the Edge Transport server, transport agents and content conversion can act on message classifications in the perimeter network. For example, the Attachment Filter agent can apply the Attachment Removed classification when it removes an attachment. Therefore, informational text will be displayed to a Microsoft Outlook user or a Microsoft Office Outlook Web App user to tell the recipient what happened. Agents that are developed for use by third-party applications can use message classifications in a similar manner. Also, message classifications may have to be translated by the Edge Transport server from a GUID in an X-header to Transport Neutral Encapsulation Format (TNEF) as a localized recipient description. Remote domains All remote domain policies configured for the Exchange organization are written to AD LDS. Remote domain policies control out-of-office message settings and message format settings for a remote domain. For more information about remote domains, see Understanding Remote Domains. Send connectors By default, Send connectors required to enable end-to-end mail flow between the Exchange organization and the Internet are automatically created. Any existing Send connectors on the Edge Transport server are deleted. If you want to configure additional Send connectors, you configure the Send connector inside the Exchange organization and select the Edge Subscription as the source server for the connector. For more information, see Understanding Edge Subscriptions. Internal SMTP servers The value for the InternalSMTPServers attribute is stored on the TransportConfig object for both the Exchange organization and the local Edge Transport server. During the EdgeSync synchronization process, the value that's stored on the local Edge Transport server object is overwritten with the value that's stored on this object for the Exchange organization. This attribute specifies a list of internal SMTP server IP addresses or IP address ranges that should be ignored by Sender ID and connection filtering. Domain Secure lists The TLSReceiveDomainSecureList and the TLSSendDomainSecureList attributes are stored on the TransportConfig object for both the Exchange organization and the local Edge Transport server. During the EdgeSync synchronization process, the value that's stored on the local Edge Transport server object is overwritten with the value that's stored on this object for the Exchange organization. These attributes specify the list of remote domains that are configured for mutual TLS authentication.

Recipient Information
The recipient information that's replicated to AD LDS includes only a subset of the recipient attributes. Only the data that the Edge Transport server must have to perform certain anti-spam tasks is replicated. The recipient information replicated to AD LDS includes the following:

Recipients The list of recipients in the Exchange organization is replicated to AD LDS. Each recipient is identified by the GUID assigned to it in Active Directory. If you configure a recipient's user account to deny receipt of mail from outside the organization, the recipient isn't replicated to AD LDS. If you disable or delete the mailbox for a recipient, it isn't replicated to AD LDS. Proxy addresses All proxy addresses assigned to each recipient are replicated to AD LDS as hashed data. This is a one-way hash that uses Secure Hash Algorithm (SHA)-256. SHA-256 generates a 256-bit message digest of the original data. Storing proxy addresses as hashed data helps secure this information in case the Edge Transport server or AD LDS is compromised. Proxy addresses are referenced when the Edge Transport server performs the recipient lookup antispam task. Safe Senders List, Blocked Senders List, and Safe Recipients List The Safe Senders Lists, Blocked Senders Lists and Safe Recipients Lists that are defined in each recipient's Outlook instance are aggregated and replicated to AD LDS. These settings are stored on the mailbox store where the recipient's mailbox resides. An Outlook user's safelist collection is the combined data from the user's Safe Senders List, Safe Recipients List, Blocked Senders List, and external contacts. Having safelist collection data available in AD LDS enables the Edge Transport server to screen senders appropriately, reducing the operational overhead involved with filtering mail. This information is sent as hashed data. Important: Although the safe recipient data is stored in Outlook and can be aggregated into the safelist collection on the AD LDS instance on the Edge Transport server, the content filtering functionality doesn't act on safe recipient data. Per recipient anti-spam settings By using the Set-Mailbox cmdlet, you can assign anti-spam threshold settings per recipient that differ from the organizationwide anti-spam settings. If you configure per recipient anti-spam settings, these settings override the organization-wide settings. By replicating these settings to AD LDS, the per recipient settings can be considered before the message is relayed to the Exchange organization. This information is sent as hashed data.

Topology Information
The topology information includes notification of newly subscribed Edge Transport servers or removed Edge Subscriptions. This data is refreshed every five minutes.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Edge Subscription Credentials

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-01-18 This topic explains how the Edge Subscription process provisions the credentials that are used to help secure the EdgeSync synchronization process in Microsoft Exchange Server 2010 and how the Microsoft Exchange EdgeSync service uses those credentials to establish a secure LDAP connection between a Hub Transport server and an Edge Transport server. To learn more about the Edge Subscription process, see Understanding Edge Subscriptions. Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents Edge Subscription Process EdgeSync Replication Accounts Authenticating Initial Replication Authenticating Scheduled Synchronization Sessions Renewing EdgeSync Replication Accounts

Edge Subscription Process

The Edge Transport server is subscribed to an Active Directory site to establish a synchronization relationship between the Hub Transport servers in an Active Directory site and the subscribed Edge Transport server. The credentials that are provisioned during the Edge Subscription process are used to help secure the LDAP connection between a Hub Transport server and an Edge Transport server in the perimeter network. When you run the New-EdgeSubscription cmdlet in the Exchange Management Shell on an Edge Transport server, the EdgeSync bootstrap replication account (ESBRA) credentials are created in the Active Directory Lightweight Directory Services (AD LDS) directory on the local server and then written to the Edge Subscription file. These credentials are used only to establish the initial synchronization and will expire 1,440 minutes (24 hours) after the Edge Subscription file is created. If the Edge Subscription process isn't completed within that time, you must run the New-EdgeSubscription cmdlet in the Shell on the Edge Transport server again to create an Edge Subscription file. The following table describes the data contained in the Edge Subscription XML file.

Edge Subscription file contents

Subscription data EdgeServerName EdgeServerFQDN Description The NetBIOS name of the Edge Transport server. The name of the Edge Subscription in Active Directory will match this name. The fully qualified domain name (FQDN) of the Edge Transport server. The Hub Transport servers in the subscribed Active Directory site must be able to locate the Edge Transport server by using Domain Name System (DNS) to resolve the FQDN. The public key of the Edge Transport server's self-signed certificate. The name assigned to the ESBRA. The ESBRA account has the following format: ESRA.Edge Transport server name. ESRA means EdgeSync replication account. The password assigned to the ESBRA. The password is generated by using a random number generator and is stored in the Edge Subscription file in clear text. The creation date of the Edge Subscription file. The length of time that these credentials will be valid before they expire. The ESBRA account is valid for only 24 hours. The secure LDAP port to which the EdgeSync service binds when synchronizing data from Active Directory to AD LDS. By default, this is TCP port 50636. The licensing information for the Edge Transport server. After an Edge Transport server is subscribed to Active Directory, the licensing information about the Edge Transport server is displayed in the Exchange Management Console for the Exchange organization. You must license the Edge Transport server before you create the Edge Subscription for this information to be displayed correctly. The version number of the Edge Subscription file. The version of Exchange Server that is installed on the Edge Transport server.

EdgeCertificateBlob ESRAUsername

ESRAPassword

EffectiveDate Duration AdamSslPort

ProductID

VersionNumber SerialNumber Important:

The ESBRA credentials are written to the Edge Subscription file in clear text. You must protect this file throughout the subscription process. After the Edge Subscription file is imported to your Exchange organization, you should immediately delete the Edge Subscription file from the Edge Transport server, the network

share you used to import the file to your Exchange organization, and any removable media. Return to top

EdgeSync Replication Accounts

EdgeSync replication accounts (ESRA) are an important part of EdgeSync security. Authentication and authorization of the ESRA is the mechanism used to help secure the connection between an Edge Transport server and a Hub Transport server. The ESBRA contained in the Edge Subscription file is used to establish a secure LDAP connection during the initial synchronization. After the Edge Subscription file is imported to a Hub Transport server in the Active Directory site to which the Edge Transport server is being subscribed, additional ESRA accounts are created in Active Directory for each Edge Transport-Hub Transport server pair. During initial synchronization, the newly created ESRA credentials are replicated to AD LDS. These ESRA credentials are used to help secure later synchronization sessions. Each EdgeSync replication account is assigned the properties described in the following table.

Ms-Exch-EdgeSyncCredential properties
Property name TargetServerFQDN SourceServerFQDN EffectiveTime ExpirationTime UserName Password Type String String DateTime (UTC) DateTime (UTC) String Byte Description The Edge Transport server that will accept these credentials. The Hub Transport server that will present these credentials. This value is empty if the credential is the bootstrap credential. When to start using this credential. When to stop using this credential. The user name that's used to authenticate. The password that's used to authenticate. The password is encrypted by using ms-Exch-EdgeSync-Certificate.

The following sections of this topic describe how the ESRA credentials are provisioned and used during the EdgeSync synchronization process.

Provisioning the EdgeSync Bootstrap Replication Account

When the New-EdgeSubscription cmdlet is run on the Edge Transport server, the ESBRA is provisioned as follows:

A self-signed certificate (Edge-Cert) is created on the Edge Transport server. The private key is stored in the local computer store and the public key is written to the Edge Subscription file. The ESBRA (ESRA.Edge) is created in AD LDS, and the credentials are written to the Edge Subscription file. The Edge Subscription file is exported by copying it to removable media. The file is now ready to import to a Hub Transport server.

Provisioning EdgeSync Replication Accounts in Active Directory

When the Edge Subscription file is imported on a Hub Transport server, the following steps occur to establish a record of the Edge Subscription in Active Directory and to provision additional ESRA credentials.

1. An Edge Transport server configuration object is created in Active Directory. The Edge-Cert certificate is written to this object as an attribute. 2. Every Hub Transport server in the subscribed Active Directory site receives an Active Directory notification that a new Edge Subscription has been registered. As soon as the notification is received, each Hub Transport server retrieves the ESRA.Edge account and encrypts the account by using the Edge-Cert public key. The encrypted ESRA.Edge account is written to the Edge Transport server configuration object. 3. Each Hub Transport server creates a self-signed certificate (Hub-Cert). The private key is stored in the local computer store and the public key is stored in the Hub Transport server configuration object in Active Directory. 4. Each Hub Transport server encrypts the ESRA.Edge account by using the public key of its own Hub-Cert certificate and then stores it in its own configuration object. 5. Each Hub Transport server generates an ESRA for each existing Edge Transport server configuration object in Active Directory (ESRA.Hub.Edge). The account name is generated by using the following naming convention: ESRA.<Hub Transport server NetBIOS Name>.<Edge Transport server NetBIOS Name>.<Effective Date UTC Time> Example: ESRA.Hub.Edge.01032010 The password for ESRA.Hub.Edge is generated by a random number generator and is encrypted by using the public key of the Hub-Cert certificate. The generated password has the maximum length allowed for Microsoft Windows Server. 6. Each ESRA.Hub.Edge account is encrypted by using the public key of the Edge-Cert certificate and is stored on the Edge Transport server configuration object in Active Directory. The following sections of this topic explain how these accounts are used during the EdgeSync synchronization process. Return to top

Authenticating Initial Replication

The ESBRA account, ESRA.Edge, is used only when establishing the initial synchronization session. During the first EdgeSync synchronization session, the additional ESRA accounts, ESRA.Hub.Edge, are replicated to AD LDS. These accounts are used to authenticate later EdgeSync synchronization sessions.

The Hub Transport server that performs the initial replication is determined randomly. The first Hub Transport server in the Active Directory site to perform a topology scan and discover the new Edge Subscription performs the initial replication. Because this discovery is based on the timing of the topology scan, any Hub Transport server in the site may perform the initial replication. The Microsoft Exchange EdgeSync service initiates a secure LDAP session from the Hub Transport server to the Edge Transport server. The Edge Transport server presents its self-signed certificate and the Hub Transport server verifies that the certificate matches the certificate that's stored on the Edge Transport server configuration object in Active Directory. After the Edge Transport server's identity is verified, the Hub Transport server provides the credentials of the ESRA.Edge account to the Edge Transport server. The Edge Transport server verifies the credentials against the account that's stored in AD LDS. The Microsoft Exchange EdgeSync service on the Hub Transport server then pushes the topology, configuration, and recipient data from Active Directory to AD LDS. The change to the Edge Transport server configuration object in Active Directory is replicated to AD LDS. AD LDS receives the newly added ESRA.Hub.Edge entries and the Microsoft Exchange Credential Service creates the corresponding AD LDS account. These accounts are now available to authenticate later scheduled EdgeSync synchronization sessions.

Microsoft Exchange Credential Service

The Microsoft Exchange Credential Service is part of the Edge Subscription process. It runs only on the Edge Transport server. This service creates the reciprocal ESRA accounts in AD LDS so that a Hub Transport server can authenticate to an Edge Transport server to perform EdgeSync synchronization. The Microsoft Exchange EdgeSync service doesn't communicate directly with the Microsoft Exchange Credential Service. The Microsoft Exchange Credential Service communicates with AD LDS and installs the ESRA credentials whenever the Hub Transport server updates them. Return to top

Authenticating Scheduled Synchronization Sessions

After initial EdgeSync synchronization finishes, the EdgeSync synchronization schedule is established and data that has changed in Active Directory is regularly updated in AD LDS. A Hub Transport server initiates a secure LDAP session with the AD LDS instance on the Edge Transport server. AD LDS proves its identity to that Hub Transport server by presenting its self-signed certificate. The Hub Transport server presents its ESRA.Hub.Edge credentials to AD LDS. The ESRA.Hub.Edge password is encrypted by using the Hub Transport server's self-signed certificate's public key. This means that only that particular Hub Transport server can use those credentials to authenticate to AD LDS. Return to top

Renewing EdgeSync Replication Accounts

The password for the ESRA account must comply with the local server's password policy. To prevent the password renewal process from causing temporary authentication failure, a second ESRA.Hub.Edge account is created seven days before the first ESRA.Hub.Edge account expires with an effective time that's three days before the first ESRA expiration time. As soon as the second ESRA account becomes effective, EdgeSync stops using the first account and starts to use the second account. When the expiration time for the first account is reached, those ESRA credentials are deleted. This renewal process will continue until the Edge Subscription is removed. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Edge Transport Server Cloned Configuration

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 The Microsoft Exchange Server 2010 Edge Transport server role stores its configuration information in Active Directory Lightweight Directory Services (AD LDS). You can install more than one Edge Transport server in the perimeter network and use Domain Name System (DNS) round robin, a simple mechanism that's used by DNS servers to share and distribute loads for network resources, to help balance network traffic among the Edge Transport servers. To make sure that all Edge Transport servers that you deploy are using the same configuration information, you can use the provided cloned configuration scripts in the Exchange Management Shell to duplicate the configuration of a source server to a target server. You use cloned configuration to deploy new Edge Transport servers based on a configured source server. The configuration information for the source server is duplicated and then exported to an XML file. The XML file is then imported to the target server. This topic provides an overview of the cloned configuration process. For detailed steps about configuring your Edge Transport servers using cloned configuration, see Configure Edge Transport Server Using Cloned Configuration.

Cloned Configuration and EdgeSync

Run the EdgeSync process after you import the cloned configuration. To perform recipient lookup and message security tasks, the computer that has the Edge Transport server role installed requires data that resides in Active Directory. EdgeSync is a collection of processes that are run on a computer that has the Hub Transport server role installed to establish one-way replication of recipient and configuration information from Active Directory to the AD LDS instance on an Edge Transport server. The Microsoft Exchange EdgeSync service copies only the information that's required for the Edge Transport server to perform anti-spam tasks and the information about the connector configuration that's required to enable end-to-end mail flow. The Microsoft Exchange EdgeSync service performs scheduled updates so that the information in AD LDS remains current. Cloned configuration doesn't duplicate the Edge Subscription settings of a server. The certificates that are used by the Microsoft Exchange EdgeSync service aren't cloned. You must run the EdgeSync process separately for each Edge Transport server. The Microsoft Exchange EdgeSync service overwrites any settings that are included in both cloned configuration information and in EdgeSync replication information. These settings include Send connectors, Receive connectors, accepted domains, and remote domains.

Cloned Configuration Process

The cloned configuration process consists of three steps:

1. Export the configuration on the source server. In this step, you run the ExportEdgeConfig.ps1 script to export the source server's configuration information to an intermediate XML file. 2. Validate the configuration on the target server. In this step, you run the ImportEdgeConfig.ps1 script. This script checks the existing information in the intermediate XML file to see whether the settings that were exported are valid for the target server and then creates an answer file. The answer file specifies the server-specific information that's used during the next step when you import the configuration on the target server. The answer file contains entries for each source server setting that isn't valid for the target server. You can modify these settings so that they're valid for the target server. If all settings are valid, the answer file contains no entries. 3. Import the configuration on the target server. In this step, the ImportEdgeConfig.ps1 script uses the intermediate XML file and the answer file to clone an existing configuration or to restore the server to a specific configuration. These steps are described in detail in the following sections.

Step 1: Export the Configuration

After you install and configure the Edge Transport server role, run the ExportEdgeConfig.ps1 script. This script retrieves the source server's configuration information and stores the information in an intermediate XML file. The following information is exported from the source server and stored in the intermediate XML file:

Transport server-related information and log file path information. The following file paths are exported: ReceiveProtocolLogPath SendProtocolLogPath MessageTrackingLogPath PickupDirectoryPath RoutingTableLogPath Transport agent-related information that includes the status and priority settings of each transport agent. All Send connector-related information. If any Send connectors are configured to use credentials, the password is written to the intermediate XML file as an encrypted string. You can use the -key parameter with the ImportEdgeConfig.ps1 and ExportEdgeConfig.ps1 scripts to specify the 32-byte string to use for password encryption and decryption. If you don't use the -key parameter, a default encryption key is used. Receive connector-related information. To modify the local network binding and port properties, you must modify the configuration information in the answer file that's created in the validate configuration step. Accepted domain configuration. Remote domain configuration. Anti-spam features configuration settings. The following information is exported: IP Allow list information. Only the IP Allow list entries that were manually configured by the administrator are exported. IP Block list information. Content filter configuration. Recipient filter configuration.

Address rewrite entries. Attachment filter entries.

Step 2: Validate the Configuration

The target server is an Exchange 2010 server that has a clean installation of the Edge Transport server role. Run the ImportEdgeConfig.ps1 script on the target server to validate the existing information in the intermediate XML file and to create the answer file. The answer file specifies the server-specific information that's used during the next step in the cloned configuration process when you import the configuration on the target server. The answer file contains entries for each source server setting that isn't valid for the target server. You can modify these settings so that they're valid for the target server. If all settings are valid, the answer file contains no entries. The intermediate XML file can be used for different target servers. The answer file is specific to a target server. The ImportEdgeConfig.ps1 script performs the following tasks during this step:

The script verifies that the data paths and log paths can be created on the target server. If the paths can't be created, a blank path is inserted into the answer file. For each Send connector in the XML file, the script adds a blank entry for the source IP address in the answer file. For each Receive connector in the XML file, the script adds a blank entry for the local network bindings in the answer file. You must manually modify the answer file to provide the following information about server-specific settings:

Fill in the data paths and log paths. If these paths are left blank in the answer file, the paths that are configured in the intermediate XML file are used in the next step when you import the configuration on the target server. For each Send connector entry, fill in the source IP address. If this field is left blank, an error occurs in the import configuration step. For each Receive connector entry, fill in the local network bindings. If the local network bindings are left blank, an error occurs in the next step when you import the configuration on the target server.

Step 3: Import the Configuration

Perform this step on any target server to clone the configuration of an existing Edge Transport server or to restore the server to a specific configuration. Run the ImportEdgeConfig.ps1 script to validate and import the new configuration. After you run this script, the target server's configuration matches the settings in the intermediate XML file and the answer file. Important: It's a best practice to back up the existing server configuration before you run the import configuration process, so that if the cloning operation fails, the server can be restored to the previous stable state. This step uses the server-specific information that's provided in the answer file. If a setting isn't specified in the answer file, the data in the intermediate XML file is used. Before the script modifies the configuration, the script validates the data in the intermediate XML file and the answer file. The following configuration settings of the target server are modified during the import configuration step:

The transport agent configuration is modified. The existing connectors on the target server are removed, and the connectors that are present in the intermediate XML file are added. The existing accepted domains are removed, and the accepted domain entries in the intermediate XML file are added. The existing remote domains are removed, and the remote domain entries in the intermediate XML file are added. The existing IP Allow list entries are removed, and the IP Allow list entries in the intermediate remote domains file are added. The existing IP Block list entries are removed, and the IP Block list entries in the intermediate remote domains file are added. The following anti-spam configuration is cloned to the target server: Content filter configuration Recipient filter configuration Address rewrite entries Attachment filter entries

Transport Configuration Information

The settings of the transport configuration object define server-wide e-mail transport settings for an Edge Transport server. When you import the intermediate XML file to the target server, all the settings of the transport configuration object except for the following are imported:

General names and creation dates from the exported XML file Send connector information Receive connector information Attachment filter entries The MaxDumpsterSizePerStorageGroup attribute entry After the import process is complete, you may also configure the settings by using the Set-TransportConfig cmdlet. For more information, see Set-TransportConfig. The following table describes the attributes that are associated with the transport configuration object and the default values. You configure this object on both Hub Transport servers and Edge Transport servers. However, many attributes apply only to Hub Transport servers and configuring those attributes on an Edge Transport server will have no effect.

Transport configuration attributes and default values

Attribute Description Default value

ClearCategories GenerateCopyOfDSNFor

This attribute specifies whether to clear Microsoft Office Outlook categories during content conversion. This attribute specifies the delivery status notification (DSN) codes that cause the DSN message to be copied to the postmaster e-mail address. DSN codes are entered as x.y.z and are separated by commas.

True 5.4.8, 5.4.6, 5.4.4, 5.2.4, 5.2.0, 5.1.4 Null

InternalSMTPServers

This attribute specifies a list of internal SMTP server IP addresses or IP address ranges that should be ignored by Sender ID and connection filtering. This attribute specifies the e-mail address to which journal reports are sent if the journaling mailbox is unavailable. This attribute doesn't apply to the configuration of an Edge Transport server. This attribute specifies the maximum size of the transport dumpster on a Hub Transport server. This attribute doesn't apply to the configuration of an Edge Transport server. This attribute specifies how long an e-mail message should remain in the transport dumpster on a Hub Transport server. This attribute doesn't apply to the configuration of an Edge Transport server. This attribute specifies the maximum message size that can be received by recipients in the organization. This attribute doesn't apply to the configuration of an Edge Transport server. This attribute specifies the maximum number of recipients that are allowed in a single e-mail message. This attribute doesn't apply to the configuration of an Edge Transport server. This attribute specifies the maximum message size that can be sent by senders in the organization. This attribute doesn't apply to the configuration of an Edge Transport server. This attribute specifies the remote domains that will use mutual Transport Layer Security (TLS) authentication through Receive connectors configured to support Domain Security. Multiple domains may be separated by commas. The wildcard character (*) isn't supported in the domains that are listed in this attribute. This attribute specifies the remote domains that will use mutual TLS authentication when e-mail is sent through a Send connector configured to support Domain Security and the address space of the target domain. Multiple domains may be separated by commas. The wildcard character (*) isn't supported in the domains that are listed in this attribute. This attribute verifies that e-mail clients that are submitting messages from mailboxes on Mailbox servers are using encrypted MAPI submission. This attribute doesn't apply to the configuration of an Edge Transport server. The valid values for this attribute are $true or $false. This attribute specifies whether Unified Messaging voice mail is journaled by the Journaling agent. This attribute doesn't apply to the configuration of an Edge Transport server. This attribute specifies whether Xexch50 authentication should be enabled for backward compatibility with Exchange Server 2003 servers.

JournalingReportNdrTo

Null

MaxDumpsterSizePerStorageGroup

18 MB

MaxDumpsterTime

7.00:00:00

MaxReceiveSize

10 MB

MaxRecipientEnvelopeLimit

5,000

MaxSendSize

10 MB

TLSReceiveDomainSecureList

Null

TLSSendDomainSecureList

Null

VerifySecureSubmitEnabled

False

VoicemailJournalingEnabled

True

Xexch50Enabled

True

Note: If the Edge Transport server is subscribed to the Exchange organization later, the value of the InternalSMTPServers attribute is overwritten during the EdgeSync process. For more information, see Understanding Edge Subscriptions.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding the EdgeTransport.exe.Config File

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-11-09 The EdgeTransport.exe.config file is an XML application configuration file that is associated with the EdgeTransport.exe file. By default, it's located in the C:\Program Files\Microsoft\Exchange Server\V14\Bin directory. EdgeTransport.exe and MSExchangeTransport.exe are the executable files that are used by the Microsoft Exchange Transport service. This service runs on every Hub Transport server or Edge Transport server. Changes that are saved to the EdgeTransport.exe.config file are applied after the Microsoft Exchange Transport service is restarted. The default value is enforced if either of the following conditions is true:

A configuration option is missing. A configuration option is present and contains the default value. The following example shows the typical structure of the EdgeTransport.exe.config file: <configuration> <runtime> <gcServer enabled="true" /> </runtime> <appSettings> <add key="Configuration Option" value="Value" /> ... </appSettings> </configuration> You can add new configuration options or modify existing configuration options in the <appSettings> section.

Note: The parameter names in the <add key=../> section are case sensitive. 2010 Microsoft Corporation. All rights reserved.
2013 Microsoft. All rights reserved.

Understanding Exchange 2010 Support for X.400 Authoritative Domains

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-01-18 This topic describes the support that Microsoft Exchange Server 2010 provides for X.400 domains. Exchange 2010 enables the configuration of one or more X.400 authoritative domain namespaces by using Exchange Management Shell commands. Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents X.400 Addresses Configuring X.400 Authoritative Domains Recipient Resolution and Routing for X.400 Authoritative Domains

X.400 Addresses

An X.400 address is an address that's defined as part of a suite of e-mail standards that are defined by International Telecommunication Union - Telecommunication [Standardization Sector] (ITU-T) recommendations. An X.400 address uses a hierarchical naming system and consists of a series of attributes, the sum of which form the X.400 address. Some attributes in the address specify the organization. Other attributes specify the recipient. The sum of all the organizational attributes specifies a unique node in the X.400 address hierarchy. Exchange 2010 doesn't support the following X.400 scenarios:

Sharing an X.400 address node with another e-mail system. In Exchange 2010, you can share an SMTP domain namespace by configuring an internal relay accepted domain. You can't use this configuration for an X.400 namespace. Exchange 2010 must be authoritative for the X.400 domain. Alternatively, the X.400 domain must be configured as an external relay subdomain of an authoritative X.400 domain. Configuring an X.400 authoritative domain on the Edge Transport server. Configuring an X.400 authoritative domain in the Exchange Management Console. You must use the Shell to configure X.400 authoritative domains. Routing or relaying directly to an X.400 message transfer agent (MTA). Exchange 2010 must route through a source server that's running Microsoft Exchange Server 2003 and hosting an X.400 connector, or through a third-party Exchange 2010 X.400 connector. Return to top

Configuring X.400 Authoritative Domains

You configure an X.400 authoritative domain on the Hub Transport server role. When an organization is configured as authoritative for a particular domain, it's assumed that the organization hosts all the mailboxes for recipients in that domain. After you create an X.400 authoritative domain name, you can create an e-mail address policy that specifies that domain in the e-mail proxy address. The Exchange organization accepts e-mail that's addressed to recipients who have been assigned an X.400 e-mail proxy address that uses the X.400 authoritative domain namespace. Any X.400 recipient addresses in the authoritative namespace that don't resolve to a mailbox or a contact in Active Directory are treated as an error and cause messages to result in a non-delivery report (NDR). If the message that causes the error is a delivery status notification (DSN), such as an NDR, it's deleted. Exchange 2010 supports non-authoritative X.400 domains if they're a subdomain of an authoritative domain. You use the X400ExternalRelay parameter of the NewX400AuthoritativeDomain cmdlet to define any exceptions where the Exchange organization isn't authoritative for a subdomain of the authoritative X.400 domain. By default, the value of the X400ExternalRelay parameter is set to $false. Therefore, a recipient resolution failure for an e-mail message that's sent to a recipient in the X.400 subdomain results in an NDR. If the value of the X400ExternalRelay parameter is set to $true, Exchange doesn't treat recipient resolution failures as an error and routes messages that are addressed to a recipient in the X.400 subdomain to an external address.

Defining an X.400 Namespace

By default, when you configure an X.400 authoritative domain, the Exchange organization is considered authoritative for all X.400 addresses in the hierarchy. An X.400 address consists of a series of attributes that define organizational components and specify recipients. The X.400 namespace that's specified in the X400DomainName parameter can only include the X.400 organizational components. The following table lists the attributes that you can use to define an X.400 domain namespace in Exchange 2010. The attributes are listed in hierarchical order.

X.400 organizational components

Attribute abbreviation Organizational component Required/Optional Maximum character length 2

Country The value of the Country attribute is the two-letter country/region designation from International Organization for Standardization (ISO) 3166. This attribute identifies the country or region of the X.400 domain

Required

namespace. A ADMD The value of the Administration Management Domain (ADMD) typically identifies a public mail service provider. Valid values are decided on a country or regional basis. PRMD The value of the Private Management Domain (PRMD)defines the top level domain in the namespace of the Exchange organization. Organization The value of the Organization attribute is unique within the context of the PRMD or of the ADMD if there is no PRMD. Organizational unit 1 The value of each organizational unit identifies a unique address element within the scope of the immediately superior address element in the hierarchy. Organizational unit 2 The value of each organizational unit identifies a unique address element within the scope of the immediately superior address element in the hierarchy. Organizational unit 3 The value of each organizational unit identifies a unique address element within the scope of the immediately superior address element in the hierarchy. Organizational unit 4 The value of each organizational unit identifies a unique address element within the scope of the immediately superior address element in the hierarchy. Required 16

Optional

16

Optional

64

OU1

Optional

64

OU2

Optional

64

OU3

Optional

64

OU4

Optional

64

When you specify the X.400 namespace, the address attributes must be separated by semicolons and the address must be enclosed in quotation marks ("), as in the following example.

"C=US;A=ATT;P=Contoso;O=Example"

X.400 domain names can only include the following ASCII characters:

A to Z a to z 09 These punctuation and special characters: (space) ' () + , - . / : = ? The inclusion of a wildcard character, such as an asterisk (*), isn't supported in the X.400 authoritative namespace. Each attribute can appear only one time in the X.400 namespace. Any address in the hierarchy that's subordinate to the defined organizational components must resolve to a recipient or contact in Active Directory, unless an exception has been defined for a subdomain by specifying the X400ExternalRelay parameter as $true. If the categorizer can't resolve a recipient, an NDR is generated for a message. If the message is a DSN, it's deleted. For example, if you've configured an X.400 authoritative domain as "C=US;A=ATT;O=Contoso", the Exchange organization is also considered authoritative for the X.400 namespace "C=US;A=ATT;O=Contoso;OU1=Tailspin Toys". If all the recipients for Tailspin Toys are located in another organization, each of those recipients must be represented as a contact in the Active Directory of the Contoso organization. If you can't do this, the Tailspin Toys namespace must be defined as an external relay subdomain. Return to top

Recipient Resolution and Routing for X.400 Authoritative Domains

To determine how to handle routing of e-mail messages, the Exchange 2010 categorizer compares the recipient addresses to the list of domains for which the Exchange organization is authoritative. This enables the categorizer to determine when to route an X.400 addressed message to an external system and when to generate an NDR for a message if the recipient isn't found in the authoritative namespace. If a message is being sent to a recipient address in an X.400 domain for which the Exchange organization is authoritative, the message is delivered to valid recipients, In addition, an NDR is returned to the sender for any recipient that doesn't appear in Active Directory. If a message is being sent to an X.400 domain for which the Exchange organization isn't authoritative, the message is routed externally through an X.400 connector. After an X.400 authoritative namespace has been defined, the Exchange organization is assumed to be responsible for message delivery to all recipients that have email proxy addresses that match the namespace. Therefore, X.400 addressed messages that are received by an Exchange 2010 Hub Transport server are processed as follows:

If the recipient address resolves to a recipient in Active Directory, the message is delivered. An NDR is returned to the sender if all the following conditions are true: The recipient address doesn't resolve to a recipient in Active Directory. The recipient address matches an X.400 namespace for which Exchange is authoritative. The e-mail is a message. The e-mail is deleted if all the following conditions are true: The recipient address doesn't resolve to a recipient in Active Directory. The recipient address matches an X.400 namespace for which Exchange is authoritative. The e-mail is a DSN. The e-mail is routed to an X.400 connector if all the following conditions are true: The recipient address doesn't resolve to a recipient in Active Directory. The recipient address doesn't match an X.400 namespace for which Exchange is authoritative. The e-mail is routed to an X.400 connector. Although you can configure recipients to receive e-mail that's addressed to an X.400 namespace, Exchange 2010 doesn't provide native transport support for X.400. To

send or receive X.400 e-mail messages to or from remote X.400 domains, you must maintain one or more X.400 connectors on an Exchange 2003 server, or configure a Foreign connector to the X.400 backbone. Exchange 2010 doesn't have an X.400 MTA. Therefore, Exchange 2010 can't convert messages to the X.400 format. An X.400 connector that's hosted on an Exchange 2003 server or a Foreign connector must process the message so that conversion to an X.400 message occurs. To transport X.400 messages, Exchange 2010 routes the message over SMTP as a MIME-encapsulated Transport Neutral Encapsulation Format (TNEF) message. For more information about how to create an X.400 connector on Exchange 2003, see How to Create an X.400 Connector. For more information about how to create a Foreign connector, see Create a Foreign Connector. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Foreign Connectors

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-01-26 A Foreign connector can only be installed on a computer that's running Microsoft Exchange Server 2010 and that has the Hub Transport server role installed. A Foreign connector uses a Drop directory to send messages to a local messaging server that doesn't use SMTP as its primary transport mechanism.

Overview of Foreign Connectors

Exchange 2010 Hub Transport servers require Foreign connectors to deliver messages to foreign gateway servers that don't use SMTP to transmit messages. Thirdparty fax gateway servers are examples of foreign gateway servers. A Foreign connector controls outbound connections from the Hub Transport server to the foreign gateway server. The outbound messages are put in a Drop directory on the Hub Transport server or in a network file share on a remote server. Each Foreign connector uses its own Drop directory. The foreign gateway server must be configured to obtain messages from the Drop directory that's specified for that Foreign connector. Foreign connectors that are created on Hub Transport servers are stored in Active Directory and are available to all Hub Transport servers in the organization. In Active Directory, a Foreign connector is created as an object in the connections container. When a Hub Transport server in the organization routes messages to an address space configured on a Foreign connector, the message is delivered to a source Hub Transport server for that Foreign connector to be relayed to the destination domain. You can specify several different Hub Transport servers in your organization as source servers for a Foreign connector. This provides fault tolerance for the Foreign connector. If a Hub Transport server that contains the Foreign connector is unavailable, the messages that are destined for the Foreign connector's address space are relayed by using any of the other defined and available Hub Transport servers. To provide this fault tolerance, you must make sure that the Drop directory that's specified by the Foreign connector is accessible by all Hub Transport servers that are designated as source servers for that Foreign connector. Foreign gateway servers can send messages into the Exchange 2010 organization by using the Replay directory that exists on the Hub Transport server. Correctly formatted e-mail message files that you copy to the Replay directory are submitted for delivery. For more information about the Replay directory, see Understanding the Pickup and Replay Directories.

Defining the Usage of a Foreign Connector by Using Address Spaces and Connector Scope
The address space for a Foreign connector specifies the recipient domains to which the Foreign connector will route e-mail. You can specify SMTP address spaces or non-SMTP address spaces. In Exchange 2010, the complete syntax for specifying an address space is as follows.

<AddressSpaceType>:<AddressSpace>;<AddressSpaceCost>

You can use the scope of a Foreign connector to control the visibility of the Foreign connector within the Exchange organization. By default, all Foreign connectors that you create are usable by all the Hub Transport servers in the Exchange organization. However, you can limit the scope of any Foreign connector so that it's only usable by other Hub Transport servers that exist in the same Active Directory site. The connector scope is specified by using the IsScopedConnector parameter in the New-ForeignConnector cmdlet or the Set-ForeignConnector cmdlet. When the value of this parameter is $false, the connector can be used by all Hub Transport servers in the Exchange organization. When the value of this parameter is $true, the connector can only be used by Hub Transport servers in the same Active Directory site.

Foreign Connector DSN Handling

When a message is sent with a delivery confirmation request to an address that's serviced by a Foreign connector, the sender should be notified if the recipient's messaging server can't correctly process the delivery confirmation request. A Relayed delivery status notification (DSN) notifies the sender that the recipient's messaging system is unable to forward delivery confirmation requests. By default, Relayed DSN messages aren't generated for messages sent to the address spaces that are serviced by a Foreign connector. DSN messages are defined in RFC 1894. For more information about DSN messages, see Managing Delivery Status Notifications.

Delivery Agent Connectors

Exchange 2010 introduces a new feature called Delivery Agent connector, which is also used to route messages to foreign systems that don't use the SMTP protocol. When a message is routed to a Delivery Agent connector, the associated delivery agent performs the content conversion and message delivery. Delivery Agent connectors allow queue management of Foreign connectors, thereby eliminating the need for storing messages on the file system in a Drop directory. They provide greater control over the message delivery to the foreign systems. To learn more, see Understanding Delivery Agents.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Group Metrics

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-07-07 Group metrics is the collection of the following data about distribution groups and dynamic distribution groups in your organization:

Number of members Number of members who are external to your organization Group metrics data is used to support MailTips in Microsoft Exchange Server 2010. MailTips are informative messages displayed to senders while they're composing messages. For more information about MailTips, including a full list of MailTips available in Exchange 2010, see Understanding MailTips. Group metrics data is used when deciding whether to display the following MailTips:

Large Audience This MailTip is displayed when a sender adds a distribution group whose membership count is considered a large audience as configured in your organization. By default, any message addressed to more than 25 recipients is considered a large audience. External Recipients This MailTip is displayed when a sender adds a distribution group that has members who are external to your organization. Determining these characteristics of distribution groups and dynamic distribution groups isn't a simple task. MailTips are evaluated every time a recipient is added to a message composed by a user. Calculating this information while senders compose messages isn't feasible because it would delay the display of MailTips, and it could have an adverse performance impact depending on the size of your organization. To provide this valuable information to senders without an adverse performance impact, Exchange calculates group metrics data as a background process that can be scheduled to run during nonbusiness hours. When evaluating recipients for MailTips, Exchange reads the group metrics data. Looking for management tasks related to MailTips? See Managing MailTips.

Group Metrics Generation and Distribution

By default, group metrics data is generated on the same Mailbox server that generates the offline address book (OAB). This is the case even if you explicitly disable group metrics generation on that server using the Set-MailboxServer cmdlet. The Mailbox server generates full group metrics data for all distribution groups and dynamic distribution groups every Sunday, and incremental updates for any groups that were modified since the last full generation. The day of the full group metrics data generation is fixed, but you can configure the time it's generated daily. By default, group metrics data is generated daily at a random time within two hours of midnight. The following files are associated with group metrics:

GroupMetrics-<date>T<time>.bin This binary file is the main group metrics data file. It contains the membership and external members count for all distribution groups and dynamic distribution groups in your organization. The date and time sections of the file name are separated by hyphens. For example, a group metrics data file created on January 18, 2010 at 20:00 (8:00 P.M.) has the following file name: GroupMetrics-2010-01-18T20-00-00.bin. GroupMetrics-<servername>.xml This XML file contains information about the Mailbox server configured to generate the group metrics data. This file is required by the Microsoft Exchange File Distribution service, and it points to the binary file that needs to be distributed. ChangedGroups.txt This file contains the list of groups that were updated the last time group metrics data was generated. Group metrics data won't be generated by default in the following scenarios:

You don't use OABs in your organization, or you use only public folders for OAB distribution. The server responsible for OAB generation is a server running Microsoft Exchange Server 2007 with the Mailbox server role installed. If any of these scenarios apply to you, you must configure an Exchange 2010 Mailbox server manually to start generating group metrics. For detailed steps, see Configure Group Metrics. The group metrics data is distributed to the Client Access servers using the Microsoft Exchange File Distribution service. The Microsoft Exchange File Distribution service queries Active Directory for a list of Mailbox servers that have group metrics generation enabled, and then copies the group metrics data from the closest Mailbox server every eight hours.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Header Firewall

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-01-27 In Microsoft Exchange Server 2010, header firewall is a mechanism that removes specific header fields from inbound and outbound messages. Computers that are running Exchange 2010 that have the Hub Transport server role or the Edge Transport server role installed insert custom X-header fields into the message header. An X-header is a user-defined, unofficial header field that exists in the message header. X-headers aren't specifically mentioned in RFC 2822, but the use of an undefined header field starting with X- has become an accepted way to add unofficial header fields to a message. Messaging applications, such as anti-spam, antivirus, and messaging server applications may add their own X-headers to a message. X-header fields are usually preserved but ignored by messaging servers and clients that don't use them. The X-header fields contain details about the actions that are performed on the message by the transport server, such as the spam confidence level (SCL), content filtering results, and rules processing status. Revealing this information to unauthorized sources could pose a potential security risk. Header firewall prevents the spoofing of these X-headers by removing them from inbound messages that enter the Exchange organization from untrusted sources. Header firewall prevents the disclosure of these X-headers by removing them from outbound messages that will go to untrusted destinations outside the Exchange organization. Header firewall also prevents the spoofing of standard routing headers that are used to track the routing history of a message. Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents Custom Organization X-Headers and Forest X-Headers That Are Used in Exchange 2010 Header Firewall for Organization X-Headers and Forest X-Headers Header Firewall for Routing Headers Header Firewall and Earlier Versions of Exchange

Custom Organization X-Headers and Forest X-Headers That Are Used in Exchange 2010

Organization X-headers start with X-MS-Exchange-Organization-. Forest X-headers start with X-MS-Exchange-Forest-. The following table describes some of the organization X-headers and forest X-headers that are used in messages in an Exchange 2010 organization.

Some of the organization X-headers and forest X-headers that are used in messages in an Exchange 2010 organization
X-header X-MS-ExchangeForestRulesExecuted X-MS-ExchangeOrganizationAntispam-Report X-MS-ExchangeOrganizationAuthAs X-MS-ExchangeOrganizationAuthDomain X-MS-ExchangeOrganizationAuthMechanism X-MS-ExchangeOrganizationAuthSource X-MS-ExchangeOrganizationJournal-Report X-MS-ExchangeOrganizationOriginalArrivalTime X-MS-ExchangeDescription This X-header lists the transport rules that were performed on the message.

This X-header is a summary report of the anti-spam filter results that have been applied to the message by the Content Filter agent.

This X-header is always present when the security of a message has been evaluated. This X-header specifies the authentication source. The possible values are Anonymous, Internal, External, or Partner.

This X-header is populated during Domain Secure authentication. The value is the fully qualified domain name (FQDN) of the remote authenticated domain.

This X-header specifies the authentication mechanism for the submission of the message. The value is a 2-digit hexadecimal number.

This X-header specifies the FQDN of the server computer that evaluated the authentication of the message on behalf of the organization.

This X-header identifies journal reports in transport. As soon as the message leaves the transport server, the header becomes X-MS-JournalReport.

This X-header identifies the time when the message first entered the Exchange organization.

This X-header identifies the original sender of a quarantined message when it first entered the Exchange organization.

OrganizationOriginal-Sender X-MS-ExchangeOrganizationOriginalSize X-MS-ExchangeOrganizationOriginal-Scl X-MS-ExchangeOrganization-PCL X-MS-ExchangeOrganizationQuarantine This X-header identifies the original size of a quarantined message when it first entered the Exchange organization.

This X-header identifies the original SCL of a quarantined message when it first entered the Exchange organization.

This X-header identifies the phishing confidence level. The possible phishing confidence level values are from 1 through 8. A larger value indicates a suspicious message. For more information, see Understanding Anti-Spam Stamps. This X-header indicates that the message has been quarantined in the spam quarantine mailbox and a delivery status notification (DSN) has been sent. Alternatively, it indicates that the message was quarantined and released by the administrator. This X-header field prevents the released message from being submitted to the spam quarantine mailbox again. For more information, see Release Quarantined Messages from the Spam Quarantine Mailbox. This X-header identifies the SCL of the message. The possible SCL values are from 0 through 9. A larger value indicates a suspicious message. The special value -1 exempts the message from processing by the Content Filter agent. For more information, see Understanding Content Filtering. This X-header contains the results of the Sender ID agent. The Sender ID agent uses the sender policy framework (SPF) to compare the message's source IP address to the domain that's used in the sender's e-mail address. The Sender ID results are used to calculate the SCL of a message. For more information, see Understanding Sender ID.

X-MS-ExchangeOrganization-SCL

X-MS-ExchangeOrganizationSenderIdResult Return to top

Header Firewall for Organization X-Headers and Forest X-Headers

Exchange 2010 applies header firewall to organization X-headers and forest X-headers that exist in messages in the following ways:

Permissions that can be used to preserve or remove specific X-headers in messages are assigned to Send connectors or Receive connectors. Header firewall is automatically implemented for X-headers in messages during other types of message submission.

How Header Firewall Is Applied to Organization X-Headers and Forest X-headers in Messages
Header firewall for organization X-headers and forest X-headers that exist in inbound messages consists of two specific permissions that are assigned to a Receive connector that's configured on a Hub Transport server or an Edge Transport server:

If the permissions are assigned to the Receive connector, header firewall isn't applied to the message. The organization X-headers or forest X-headers in the message are preserved. If the permissions aren't applied to the Receive connector, header firewall is applied to the message. The organization X-headers or forest X-headers are removed from the message. The following table describes the header firewall permissions for organization X-headers and forest X-headers that are available on a Receive connector.

Header firewall permissions for organization X-headers and forest X-headers that are available on a Receive connector for inbound messages
By default, the security principals that have the permission assigned Permission group that has the security principals as members ExchangeServers By default, the usage type that assigns the permission groups to the Receive connector

Permission

Description

Ms-ExchAcceptHeadersOrganization

Internal

Hub Transport servers Edge Transport servers Exchange Servers Note: On Hub Transport servers only

This permission applies to organization X-headers. Organization Xheaders start with X-MS-Exchange-Organization-. If this permission isn't granted, the receiving server removes any organization headers from the message.

Ms-ExchAcceptHeadersForest

Hub Transport servers Edge

ExchangeServers

Internal

This permission applies to forest X-headers. Forest X-headers start with X-MS-Exchange-Forest-. If this permission isn't granted, the receiving server removes any forest headers from the message.

Transport servers Exchange Servers Note: On Hub Transport servers only

If you want to apply header firewall to organization X-headers and forest X-headers in a custom Receive connector scenario, use any of the following methods:

Create a Receive connector and select a usage type other than Internal. The Receive connector usage type can only be set when you create the connector. For more information, see Create an SMTP Receive Connector. Modify an existing Receive connector and remove the ExchangeServers permission group. For more information, see Configure Receive Connector Properties. Use the Remove-ADPermission cmdlet to remove the Ms-Exch-Accept-Headers-Organization permission and the Ms-Exch-Accept-Headers-Forest permission from a security principal that's configured on the Receive connector. This method doesn't work if the permission has been assigned to the security principal by using a permission group. You can't modify the assigned permissions or the group membership of a permission group. For more information, see RemoveADPermission. Use the Add-ADPermission cmdlet to deny the Ms-Exch-Accept-Headers-Organization permission and the Ms-Exch-Accept-Headers-Forest permission to a security principal that's configured on the Receive connector. For more information, see Add-ADPermission.

How Header Firewall Is Applied to Organization X-Headers and Forest X-Headers in Outbound Messages
Header firewall for organization X-headers and forest X-headers that exist in outbound messages consists of two specific permissions that are assigned to a Send connector that's configured on a Hub Transport server or an Edge Transport server:

If the permissions are assigned to the Send connector, header firewall isn't applied to the message. The organization X-headers or forest X-headers in the message are preserved. If the permissions aren't applied to the Send connector, header firewall is applied to the message. The organization X-headers and forest X-headers are removed from the message. The following table describes the header firewall permissions for organization X-headers and forest X-headers that are available on a Send connector.

Header firewall permissions for organization X-headers and forest X-headers that are available on a Send connector for outbound messages
By default, the security principals that have the permission assigned By default, the usage type that assigns the security principals to the Send connector Internal Hub Transport servers Edge Transport servers Exchange Servers Note: On Hub Transport servers only Externally Secured servers Exchange Legacy Interop universal security group Exchange Server 2003 bridgehead servers

Permission

Description

Ms-ExchSendHeadersOrganization

This permission applies to organization X-headers. Organization X-headers start with X-MS-Exchange-Organization-. If this permission isn't granted, the sending server removes any organization headers from the message.

Ms-ExchSendHeadersForest

Internal Hub Transport servers Edge Transport servers Exchange Servers Note: On Hub Transport servers only Externally Secured servers Exchange Legacy

This permission applies to forest X-headers. Forest X-headers start with X-MSExchange-Forest-. If this permission isn't granted, the sending server removes any forest headers from the message.

Interop universal security group Exchange 2003 bridgehead servers If you want to apply header firewall for organization X-headers or forest X-headers in a custom Send connector scenario, use the any of the following methods:

Create a Send connector and select a usage type other than Internal or Partner. The Send connector usage type can only be set when you create the connector. For more information, see Create an SMTP Send Connector. Remove a security principal that assigns the Ms-Exch-Send-Headers-Organization permission and the Ms-Exch-Send-Headers-Forest permission from the connector. For more information, see Configure Send Connector Properties. Use the Remove-ADPermission cmdlet to remove the Ms-Exch-Send-Headers-Organization permission and the Ms-Exch-Send-Headers-Forest permission from one of the security principals that's configured on the Send connector. For more information, see Remove-ADPermission. Use the Add-ADPermission cmdlet to deny the Ms-Exch-Send-Headers-Organization permission and the Ms-Exch-Send-Headers-Forest permission to one of the security principals that's configured on the Send connector. For more information, see Add-ADPermission.

How Header Firewall Is Applied to Organization X-Headers and Forest X-Headers from Other Message Sources
Messages can enter the Exchange 2010 transport pipeline on a Hub Transport server or an Edge Transport server without using Send connectors or Receive connectors. Header firewall for organization X-headers and forest X-headers is applied to messages originating from these other message sources as described in the following list:

Pickup directory The Pickup directory is used by administrators or applications to submit message files. Header firewall for organization X-headers and forest X-headers is always applied to the message files in the Pickup directory. For more information about the Pickup directory, see Understanding the Pickup and Replay Directories. Replay directory The Replay directory is used to resubmit messages that have been exported from Exchange 2010 message queues. How header firewall for organization X-headers and forest X-headers is applied in these messages is controlled by the X-CreatedBy: header field in the message file: If the value of this header field is MSExchange14, header firewall isn't applied to the message. If the value of X-CreatedBy: isn't MSExchange14, header firewall is applied. If the X-CreatedBy: header field doesn't exist in the message file, header firewall is applied. For more information about the Replay directory, see Understanding the Pickup and Replay Directories. Drop directory The Drop directory is used by Foreign connectors on Hub Transport servers to send messages to messaging servers that don't use SMTP to transfer messages. Header firewall for organization X-headers and forest X-headers is always applied to message files before they're put in the Drop directory. For more information about Foreign connectors, see Understanding Foreign Connectors. Store driver The store driver exists on Hub Transport servers to transport messages to and from mailboxes on Mailbox servers. For outgoing messages that are created and submitted from mailboxes, header firewall for organization X-headers and forest X-headers is always applied. For incoming messages, header firewall for organization X-headers and forest X-headers is selectively applied. The X-headers that are specified in the following list aren't blocked by header firewall for inbound messages to mailbox recipients: X-MS-Exchange-Organization-SCL X-MS-Exchange-Organization-AuthDomain X-MS-Exchange-Organization-AuthMechanism X-MS-Exchange-Organization-AuthSource X-MS-Exchange-Organization-AuthAs X-MS-Exchange-Organization-OriginalArrivalTime X-MS-Exchange-Organization-OriginalSize For more information about the store driver, see Understanding Transport Pipeline. DSN messages Header firewall for organization X-headers and forest X-headers is always applied to the original message or the original message header that's attached to the DSN message. For more information about DSN messages, see Managing Delivery Status Notifications. Agent submission Header firewall for organization X-headers and forest X-headers isn't applied to messages that are submitted by agents. Return to top

Header Firewall for Routing Headers

Routing headers are standard SMTP header fields that are defined in RFC 2821 and RFC 2822. Routing headers stamp a message by using information about the different messaging servers that were used to deliver the message to the recipient. The available routing headers are described in the following list:

Received: A different instance of this header field is added to the message header by every messaging server that accepted and forwarded the message to the recipient. The Received: header typically includes the name of the messaging server and a date-timestamp. Resent-*: Resent header fields are informational header fields that can be used to determine whether a message has been forwarded by a user. The following resent header fields are available: Resent-Date:, Resent-From:, Resent-Sender:, Resent-To:, Resent-Cc:, Resent-Bcc:, and Resent-MessageID:. The Resent fields are used so that the message appears to the recipient as if it was sent directly by the original sender. The recipient can view the message header to discover who forwarded the message. Routing headers that are inserted into messages can be used to misrepresent the routing path that a message traveled to reach a recipient. Exchange 2010 uses two different ways to apply header firewall to routing headers that exist in messages:

Permissions are assigned to Send connectors or Receive connectors that can be used to preserve or remove routing headers in messages. Header firewall is automatically implemented for routing headers in messages during other types of message submission.

How Header Firewall Is Applied to Routing Headers in Inbound Messages

Receive connectors have the Ms-Exch-Accept-Headers-Routing permission that's used to accept or reject any routing headers that exist in an inbound message:

If this permission is granted, all routing headers are preserved in the inbound message. If this permission isn't granted, all routing headers are removed from the inbound message. The following table describes the default application of the Ms-Exch-Accept-Headers-Routing permission on a Receive connector.

Default application of the Ms-Exch-Accept-Headers-Routing permission on a Receive connector

By default, the security principals that have the permission assigned Anonymous user account Authenticated user accounts Permission group that has the security principals as members Anonymous ExchangeUsers ExchangeServers By default, the usage type that assigns the permission groups to the Receive connector Internet Client (unavailable on Edge Transport servers) Internal

Hub Transport servers Edge Transport servers Exchange Servers Note: Hub Transport servers only Externally Secured servers

Exchange Legacy Interop universal security group Partner Server account

ExchangeLegacyServers Partner

Internal

Internet Partner The Ms-Exch-Accept-Headers-Routing permission is assigned to all usage types except Custom. If you want to apply header firewall to routing headers in a custom Receive connector scenario, follow these steps:

1. Perform one of the following actions: Create a Receive connector and select the usage type Custom. Don't assign any permission groups to the Receive connector. You can't modify the assigned permissions or the group membership of a permission group. Modify an existing Receive connector, and set the PermissionGroups parameter to the value None. 2. Use the Add-ADPermission cmdlet to add the appropriate security principals that are required on the Receive connector. Make sure that no security principals have the Ms-Exch-Accept-Headers-Routing permission assigned to them. If it's necessary, use the Add-ADPermission cmdlet to deny the Ms-Exch-AcceptHeaders-Routing permission to the security principal that you want to configure to use the Receive connector. For more information, see the following topics:

Create an SMTP Receive Connector Configure Receive Connector Properties Add-ADPermission Remove-ADPermission

How Header Firewall Is Applied to Routing Headers in Outbound Messages

Send connectors have the Ms-Exch-Send-Headers-Routing permission that's used to allow or remove any routing headers that exist in an outbound message:

If this permission is granted, all routing headers are preserved in the outbound message. If this permission isn't granted, all routing headers are removed from the outbound message. The following table describes the default application of the Ms-Exch-Send-Headers-Routing permission on a Send connector.

Default application of the Ms-Exch-Send-Headers-Routing permission on a Send connector

By default, the security principals that have the permission assigned By default, the usage type that assigns the security principals to the Send connector Internal Hub Transport servers Edge Transport servers Exchange Servers Note: On Hub Transport servers only Externally Secured servers Exchange Legacy Interop universal security group Exchange 2003 bridgehead servers

Anonymous User Account Partner Servers

Internet Partner

The Ms-Exch-Send-Headers-Routing permission is assigned to all usage types except Custom. If you want to apply header firewall to routing headers in a custom

Send connector scenario, use the any of following methods:

Create a Send connector and select the usage type Custom. The Send connector usage type can only be set when you create the connector. For more information, see Create an SMTP Send Connector. Remove a security principal that assigns the Ms-Exch-Send-Headers-Routing permission from the connector. For more information, see Configure Send Connector Properties. Use the Remove-ADPermission cmdlet to remove the Ms-Exch-Send-Headers-Routing permission from one of the security principals that's configured on the Send connector. For more information, see Remove-ADPermission. Use the Add-ADPermission cmdlet to deny the Ms-Exch-Send-Headers-Routing permission to one of the security principals that's configured on the Send connector. For more information, see Add-ADPermission.

How Header Firewall Is Applied to Routing Headers from Other Message Sources
Messages can enter the Exchange 2010 transport pipeline on a Hub Transport server or an Edge Transport server without using Send connectors or Receive connectors. Header firewall for routing headers is applied to the other message sources that are described in the following list:

Pickup directory The Pickup directory is used by administrators or applications to submit message files. Header firewall for routing headers is always applied to the message files in the Pickup directory. For more information about the Pickup directory, see Understanding the Pickup and Replay Directories. Store driver The store driver exists on Hub Transport servers to transport messages to and from mailboxes on Mailbox servers. Header firewall for routing headers is always applied to all messages that are sent from mailboxes on Mailbox servers. Header firewall for routing headers isn't applied to incoming messages for delivery to mailbox recipients. For more information about the store driver, see Understanding Transport Pipeline. DSN messages Header firewall for routing headers is always applied to the original message or the original message header that's attached to the DSN message. For more information about DSN messages, see Managing Delivery Status Notifications. Replay directory, Drop directory, and agent submission Header firewall for routing headers isn't applied to messages that are submitted by the Replay directory, the Drop directory, or agents. Return to top

Header Firewall and Earlier Versions of Exchange

Exchange 2003 and earlier versions of Exchange don't use the organization X-headers or forest X-headers. Exchange 2010 treats versions of Exchange earlier than Exchange 2007 as untrusted message sources. Header firewall is applied to all organization X-headers and forest X-headers in messages coming from servers that are running earlier versions of Exchange. Header firewall for organization X-headers and forest X-headers is also applied to messages that are delivered to servers that are running earlier versions of Exchange that exist in the Exchange organization. Earlier versions of Exchange use the proprietary verb X-EXCH50 to transmit information about messages and recipients that can't be included in the e-mail message. The information is transmitted as the Exch50 binary large object (BLOB). The Exch50 BLOB is a collection of binary data that's stored as a single object. Exch50 contains data such as the SCL, address rewriting information, and other MAPI properties that don't have MIME representation. Because X-EXCH50 is a proprietary Extended Simple Mail Transfer Protocol (ESMTP) verb, Exch50 data can't be propagated by a server that doesn't have Exchange installed. For more information, see Exchange 2003 - Planning Roadmap for Upgrade and Coexistence. Routing group connectors between servers that have Exchange 2010 or Exchange 2003 installed are automatically configured to support sending and receiving Exch50 data. Send connectors and Receive connectors have permissions that enable the Exch50 command. The following table describes the permissions that allow the Exch50 command on a Receive connector for inbound messages. If one of these permissions isn't granted, and a message is sent that contains the Exch50 command, the server accepts the message, but doesn't include the Exch50 command.

Permissions that allow the Exch50 command on a Receive connector for inbound messages
Permission By default, the security principals that have the permission assigned Permission group that has the security principals as members ExchangeServers By default, the usage type that assigns the permission groups to the Receive connector Internal

Ms-ExchAcceptExch50

Hub Transport servers Edge Transport servers Exchange Servers Note: On Hub Transport servers only Externally Secured servers

Ms-ExchAcceptExch50

Exchange Legacy Interop universal security group

ExchangeLegacyServers

Internal

If you want to block the Exch50 command in a custom Receive connector scenario, use the any of following methods:

Create a Receive connector and select a usage type other than Internal. The Receive connector usage type can only be set when you create the connector. For more information, see Create an SMTP Receive Connector. Modify an existing Receive connector and remove the ExchangeServers permission group. For more information, see Configure Receive Connector Properties. Use the Remove-ADPermission cmdlet to remove the Ms-Exch-Accept-Exch50 permission from a security principal that's configured on the Receive connector. This method doesn't work if the permission has been assigned to the security principal by using a permission group. You can't modify the assigned permissions or the group membership of a permission group. For more information, see Remove-ADPermission. Use the Add-ADPermission cmdlet to deny the Ms-Exch-Accept-Exch50 permission to a security principal that's configured on the Receive connector. For more information, see Add-ADPermission. The following table describes the permission that allows the Exch50 command on a Send connector for outbound messages. If this permission isn't granted and a

message is sent that contains the Exch50 command, the server sends the message, but doesn't include the Exch50 command.

Permission that allows the Exch50 command on a Send connector for outbound messages
Permission By default, the security principals that have the permission assigned By default, the usage type that assigns the security principals to the Send connector Internal Hub Transport servers Edge Transport servers Exchange Servers Note: On Hub Transport servers only Externally Secured servers Exchange Legacy Interop universal security group Exchange 2003 bridgehead servers If you want to block the Exch50 command in a custom Send connector scenario, you can use the any of following methods:

Ms-Exch-SendExch50

Create a Send connector and select a usage type other than Internal. The Send connector usage type can only be set when you create the connector. For more information, see Create an SMTP Send Connector. Remove a security principal that assigns the Ms-Exch-Send-Exch50 permission from the connector. Use the Remove-ADPermission cmdlet to remove the Ms-Exch-Send-Exch50 permission from one of the security principals that's configured on the Send connector. For more information, see Remove-ADPermission. Use the Add-ADPermission cmdlet to deny the Ms-Exch-Send-Exch50 permission to one of the security principals that's configured on the Send connector. For more information, see Add-ADPermission. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding SMTP Failover and Load Balancing in Transport

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-01-13 When you have multiple Hub Transport servers in your organization, Exchange automatically distributes the mail traffic among all the Hub Transport servers in your organization. The load distribution is successful in distributing the load evenly when all servers are available. However, when one or more servers are unavailable, the load distribution may become uneven among the remaining servers, especially if your organization is distributed across multiple Active Directory sites. In Microsoft Exchange Server 2010 Service Pack 1 (SP1), several improvements were made to the decision-making mechanism for distributing the load among Hub Transport servers. Looking for management tasks related to message routing? See Managing Message Routing. Contents Exchange Server 2010 RTM Behavior Exchange 2010 SP1 Improvements Windows Network Load Balancing or Third-Party Load Balancing Solutions with Transport Servers

Exchange Server 2010 RTM Behavior

In the release to manufacturing (RTM) version of Exchange 2010, when a transport server needs to route several messages to the same destination, the server initially determines the next hop for those messages. If there are multiple target servers for that next hop, it load balances the connection used to deliver messages equally among the target servers using the round robin manner provided by enhanced Domain Name System (DNS). For example, consider a topology where you have two Active Directory sites with three Hub Transport servers in each (as shown in the following figure). When a Hub Transport server in Site A, for example Hub02, needs to send messages to Site B, the next hop for that message is Site B. There are three possible targets in the next hop: Hub04, Hub05, and Hub06. The server will distribute the number of connections evenly across those three targets as shown in the following figure. This action results in an even distribution of messages across the connections over time.

Similarly, the Hub Transport servers in Site B will distribute the number of messages sent to recipients in Site A evenly across Hub01, Hub02, and Hub03. Also, because Edge01 is subscribed to Site A, the targets for the next hop for messages sent to the Internet are Hub01, Hub02, and Hub03. A problem arises if one or more of the servers are unavailable in the next hop. For example, assume that Hub04 in Site B is unavailable for scheduled maintenance. The servers in Site A don't maintain availability status of each server in Site B. The servers in Site A will distribute the load destined for Site B among the three Hub Transport servers in that site. However, approximately one third of those connections would be sent to Hub04 but won't succeed. These connections will fail over to the next available server, and one of the Hub Transport servers in Site B will process substantially more load than the other server as shown in the following figure.

This undesirable behavior may occur whenever there's an unavailable server in the next hop that typically has more than two targets. The next hop could be another Active Directory site as shown in the preceding example, or a connector that has multiple Hub Transport servers listed as the source server (for example, the Send connector to the subscribed Edge Transport server in the topology shown in the preceding figures). This isn't an issue for mail submissions from Mailbox servers. The mail submission service will detect unavailable Hub Transport servers in a site, and won't attempt to deliver to those servers. In the example shown previously, although one of the Hub Transport servers in Site B may have a heavier load from intersite traffic, the load generated by Mailbox servers in Site B will be evenly split between Hub05 and Hub06. Return to top

Exchange 2010 SP1 Improvements

To address the issue described in the previous section, a new component called Healthy Server Selector was added in Exchange 2010 SP1. Healthy Server Selector maintains a list of servers that are unavailable. This list is used by enhanced DNS to filter out any unavailable servers when applying round robin logic for load balancing. To demonstrate how Healthy Server Selector helps with load balancing, consider the problematic condition shown in the preceding figure. In Exchange 2010 SP1, enhanced DNS will first compile the list of potential targets in the next hop, Site B. It will then ask Healthy Server Selector to filter the list. Healthy Server Selector will report that Hub04 for the next hop Site B is unhealthy. Enhanced DNS will remove Hub04 from the list of potential targets for the next hop Site B, and will use round robin load balancing only between Hub05 and Hub06 as shown in the following figure.

Healthy Server Selector

In its simplest form, Healthy Server Selector tracks servers deemed unhealthy so that those servers aren't included in round robin load balancing. From a Healthy Server Selector perspective, a definition of an unhealthy server is one to which a connection attempt returns any Windows sockets (Winsock) error code. For each unhealthy server, Healthy Server Selector keeps the following information:

Server IP address Retry count Last retry time

Retry Behavior
When a server is marked as unhealthy, Healthy Server Selector will ensure that connections to that specific server are tried again to detect when that server comes online. Healthy Server Selector uses the following settings to determine how frequently connections will be retried to an unhealthy server:

QueueGlitchRetryInterval and QueueGlitchRetryCount These settings determine how many times and at what interval Healthy Server Selector retries connections to a specific server when it's first marked unhealthy. These settings are configured in the EdgeTransport.exe.config file. The default values for these settings are 1 minute and 4 retry attempts. These values mean that a connection to an unhealthy server will be attempted every minute four times in a default configuration. TransientFailureRetryInterval and TransientFailureRetryCount If the unhealthy server is unavailable, these settings are used by Healthy Server Selector to determine the frequency of the next set of retry attempts. These settings are configured for each transport server. The default values are 5 minutes (10 minutes on an Edge Transport server) and 6 retry attempts. These values mean that a connection to an unhealthy server will be attempted every five minutes six times after the first four minutes in a default configuration. OutboundConnectionFailureRetryInterval If the unhealthy server is unavailable, Healthy Server Selector will continue to retry the connection by the frequency specified in this parameter. This setting is configured for each transport server. The default value is 10 minutes (30 minutes on an Edge Transport server). This means that a connection will be attempted to an unhealthy server every 10 minutes after the first 34 minutes in a default configuration. For step-by-step instructions about how to configure these settings, see Configure Message Retry, Resubmit, and Expiration Intervals. When it's time to retry a connection, Healthy Server Selector allows only one connection attempt to the unhealthy server. If that connection succeeds, the SMTP outbound component will notify Healthy Server Selector that the connection is successful. At that point, Healthy Server Selector removes the server from the list of

unhealthy servers.

Healthy Server Selector and Shadow Redundancy

The shadow redundancy component of transport includes a heartbeat feature. The heartbeat is a simple SMTP connection used to query the status of messages previously submitted to a target server. Healthy Server Selector filtering won't prevent the Shadow Redundancy Manager from issuing heartbeat connection attempts. If a server has shadow messages that were submitted to a server that's unhealthy, it will attempt to make heartbeat connections to that server. If a heartbeat connection succeeds to an unhealthy server, that target server is immediately removed from the list of unhealthy servers by Healthy Server Selector. To learn more about shadow redundancy and the heartbeat, see Understanding Shadow Redundancy.

Diagnostic Information
In Exchange 2010 SP1, the connectivity logs include diagnostic information for Healthy Server Selector and the enhanced load balancing features. When a server is added to the unhealthy servers list by Healthy Server Selector, the event is logged in the connectivity log. To locate this event, search for the phrase MarkedUnhealthy in the connectivity log. On the line that contains this phrase, you can find the following information:

Target host IP address Target host fully qualified domain name (FQDN) Winsock error received Status: MarkedUnhealthy Current failure count Next retry time From this entry, you can identify the reason for the failure by evaluating the Winsock error code. For a complete list of Winsock error codes and their definitions, see Windows Sockets Error Codes. You can also determine how many connection attempts have failed and the next scheduled retry attempt to the target server by analyzing the Current Failure Count and Next Retry Time fields. You must have connectivity logging enabled on your transport servers to be able to see this diagnostic information. Connectivity logging is disabled by default on Hub Transport and Edge Transport servers. For more information about configuring connectivity logging, see Configure Connectivity Logging. Return to top

Windows Network Load Balancing or Third-Party Load Balancing Solutions with Transport Servers
As discussed earlier in this topic, Exchange 2010 automatically load balances all intra-organization message traffic between Edge Transport, Hub Transport, and Mailbox servers using enhanced DNS. However, this functionality doesn't cover the load balancing of messages received from non-Exchange sources such as external mail servers, third-party anti-spam or antivirus solutions, any internal mail servers outside your Exchange organization, line-of-business (LOB) applications, and POP-based or IMAP-based e-mail clients. If you have one or more of these mail sources, you may choose to load balance incoming SMTP traffic using a unified SMTP namespace (such as smtp.contoso.com) that distributes external e-mail messages across the transport servers within the organization. Windows Network Load Balancing (NLB) or a hardware-based load balancing solution from a third-party vendor are both supported. For a list of load balancers that have been tested by the vendor and reviewed by Microsoft to meet Exchange 2010 requirements, see Microsoft Unified Communications Load Balancer Deployment. Important: Using a load balancing solution to handle message traffic between the Exchange servers in your organization isn't supported. You must exclude message traffic between Exchange servers from any load balancing solution you deploy in your environment.

Load Balancing Inbound Internet Messages Among Your Edge Transport Servers
The most common situation is handling incoming messages from the Internet. You don't need to deploy a load balancing solution to distribute the load across your Edge Transport servers. You can accomplish this by using DNS round robin and mail exchange records (MX records) that have the same preference value, as shown in the following figure.

If you choose to use Windows NLB or a hardware load balancing solution to distribute incoming Internet messages, you need to publish a single MX record that points to your load balancing solution. The load balancer will distribute incoming messages to all the Edge Transport servers listed in its configuration, as shown in the following figure.

Load Balancing Non-Exchange Messages Among Your Hub Transport Servers

Exchange 2010 uses Receive connectors to accept incoming messages. By default, when an Exchange 2010 Hub Transport server receives an e-mail message via SMTP over TCP port 25, it's processed by the Receive connector named Default Receive connector. When a POP or IMAP client submits an e-mail message to an Exchange 2010 Hub Transport server, the message is submitted over TCP port 587 by default. This means e-mail messages submitted from POP or IMAP clients are processed by a separate Receive connector named Default Client Receive connector. If you plan on placing a load balancing solution in front of your Hub Transport servers, you should create a separate Receive connector for that purpose and make sure that only traffic processed by that particular connector is subject to load balancing. This can be achieved by adding an additional IP address to the Hub Transport server and associating this IP address with the new Receive connector. In addition, the Exchange Server authentication option should be disabled on the Receive connector to ensure Exchange traffic doesnt route over it. The following figure shows a configuration where a load balancer is used to distribute messages received from POP3 or IMAP4 clients and non-Exchange SMTP servers among two Hub Transport servers.

Windows Network Load Balancing

Windows NLB is the most common software load balancer used for Exchange servers. There are some limitations associated with deploying Windows NLB with Exchange 2010 Hub Transport servers:

Windows NLB can't be used on Exchange servers where the Hub Transport and Mailbox server roles coexist and the server also participates in a database availability group (DAG). This is because the Windows NLB feature is incompatible with Windows failover clustering. If you use an Exchange 2010 DAG and you want to use Windows NLB, you need to have the Hub Transport server role and the Mailbox server role running on separate computers. In addition, Windows NLB impacts message routing when the DAG member and Hub Transport server role coexist on the same server. To learn more, see Hub Transport and Mailbox Server Roles Coexistence When Using DAGs. We don't recommend putting more than eight Hub Transport servers in an array that's load balanced by Windows NLB. If you need to load balance more than eight Hub Transport servers, you should deploy a hardware-based solution. Windows NLB doesn't detect service outages. It only detects server outages by IP address. If the Exchange Transport service fails, but the server is still functioning, Windows NLB wont detect the failure and will still route incoming e-mail messages to that Hub Transport server. Manual intervention is required to remove the Hub Transport server experiencing the outage from the load balancing pool. Windows NLB configuration can result in port flooding, which can overwhelm networks. This is because Windows NLB has been designed in such a way that it simultaneously delivers all incoming client packets to all switch ports. Although this behavior enables Windows NLB to deliver very high throughput, it may cause high switch occupancy. For detailed steps about configuring Windows NLB, see Configure Windows Network Load Balancing for Hub Transport Servers.

Hardware Load Balancing

If you have more than eight Hub Transport servers for which you want to load balance non-Exchange message traffic, you need a more scalable load balancing solution. Although there are robust software load balancing solutions available, a hardware load balancing solution provides the most capacity. Unlike Windows NLB, which only detects server outages by IP address, a hardware load balancer can be configured to detect the failure of the Exchange Transport service and can route incoming e-mail messages to other Hub Transport servers without any manual intervention. For detailed steps about configuring a hardware load balancing solution, see Configure Hardware Load Balancing for Hub Transport Servers.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding MailTips
Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 MailTips are informative messages displayed to users while they're composing a message. Microsoft Exchange Server 2010 analyzes the message, including the list of recipients to which it's addressed, and if it detects a potential problem, it notifies the user with MailTips prior to sending the message. With the help of the information provided by MailTips, senders can adjust the message they're composing to avoid undesirable situations or non-delivery reports (NDRs). The following unproductive messaging scenarios are common in any messaging environment:

NDRs resulting from messages that violate restrictions configured in an organization such as message size restrictions or maximum number of recipients per message. NDRs resulting from messages sent to recipients that don't exist, recipients that are restricted, or users whose mailboxes are full. Sending messages to users with Automatic Replies configured. All of these scenarios involve the user sending a message, expecting it to be delivered, and instead receiving a response stating that the message isn't delivered. Even in the best-case scenario, like the automatic reply, these events result in lost productivity. In the case of an NDR, this scenario could result in a costly call to the Help desk. There are also several scenarios where sending a message won't result in an error, but can have undesirable, even embarrassing consequences:

Messages sent to extremely large distribution groups. Messages sent to inappropriate distribution groups. Messages inadvertently sent to recipients outside your organization. Selecting Reply to All to a message that was received as a Bcc recipient. All of these problematic scenarios can be mitigated by informing users of the possible outcome of sending the message as they're composing the message. For example, if senders know that the size of the message they're trying to send exceeds the corporate policy, they won't attempt to send the message. Similarly, if senders are notified that the message they're sending will be delivered to people outside the organization, they're more likely to ensure that the content and the tone of the message are appropriate. By addressing the scenarios listed earlier, MailTips can help you to:

Reduce the cost of processing and storing messages by preventing NDRs. Reduce the volume of Help desk calls caused by NDRs. Increase productivity by avoiding communications that won't succeed, for example, breaking the cycle of sending an e-mail message, receiving an automatic reply, and then redirecting the message. Inform your users as they compose e-mail messages about various policies configured in your organization that impose limits on the messages sent. Direct your users to the correct distribution groups. Reduce the risk of inadvertent disclosure of information to people outside your organization. Important: MailTips aren't designed to enforce specific policies. They simply inform the senders about the nature of the message they're composing so they can make necessary adjustments. Looking for management tasks related to MailTips? See Managing MailTips.

MailTips in Exchange 2010

The following table provides a list of MailTips in Exchange 2010.

Exchange 2010 MailTips

MailTip Invalid Internal Recipient Scenario The Invalid Internal Recipient MailTip is displayed if the sender adds a recipient that appears to be internal to the organization but doesn't exist in Active Directory. This could happen if the sender addresses a message to a user who is no longer with the company but whose address resolves due to name resolution cache or an entry in the sender's Contacts folder. It can also happen if the sender types an SMTP address with a domain for which Exchange is authoritative and the address doesn't resolve to an existing recipient. The MailTip indicates the invalid recipient and gives the sender the option to remove the recipient from the message. The Mailbox Full MailTip is displayed if the sender adds a recipient whose mailbox is full and your organization has implemented a Prohibit Receive restriction for mailboxes over a specified size. The MailTip indicates the recipient whose mailbox is full and gives the sender the option to remove the recipient from the message. The MailTip is accurate at the time of display. If the message isn't immediately sent, the MailTip is updated every two hours. This also applies to messages that were saved in the Drafts folder and reopened after two hours. The Automatic Replies MailTip is displayed if the sender adds a recipient who has turned on Automatic Replies. The MailTip indicates the recipient has Automatic Replies turned on and also displays the first 250 characters of the automatic reply configured by the recipient. The MailTip is accurate at the time of display. If the message isn't immediately sent, the MailTip is updated every two hours. This also applies to messages that were saved in the Drafts folder and reopened after two hours. If part of your user mailboxes are hosted on Exchange Online and you're in a coexistence with Exchange Online scenario, the setting on the remote domain object that represents the remote part of your organization has a direct effect on how this MailTip is processed.

Mailbox Full

Automatic Replies

In Exchange 2010, users can configure different Automatic Replies for internal and external senders. If the remote domain is configured as an internal domain (by setting the IsInternal parameter on the remote domain object to $true), the internal automatic reply is returned to all users in the organization regardless of where their mailbox resides. However, if the remote domain isn't configured as an internal domain, the internal automatic reply is returned to all users whose mailboxes are in the local domain and the external automatic reply is returned to users whose mailboxes are in the remote domain. Custom A custom MailTip is displayed if the sender adds a recipient for whom a customized MailTip is configured. A custom MailTip can be useful for providing specific information about a recipient. For example, you can create a custom MailTip for a distribution group explaining its purpose to reduce its misuse. By default, custom MailTips aren't displayed if the sender isn't allowed to send to that recipient. In that case, the Restricted Recipient MailTip is displayed. However, you can change this configuration and have the custom MailTip also display. For more information about configuring custom MailTips, see Configure Custom MailTips for Recipients. The Restricted Recipient MailTip is displayed if the sender adds a recipient for which delivery restrictions are configured prohibiting this sender from sending messages. The MailTip indicates the recipient to which the sender isn't allowed to send messages and gives the sender the option to remove the recipient from the message. It also clearly informs the sender that the message won't be delivered if sent. If the restricted recipient is an external recipient, or if it's a distribution group that contains external recipients, this information is also provided to the sender. However, the following MailTips, if applicable, are suppressed: Automatic Replies Mailbox Full Custom MailTip Moderated Recipient Oversize Message

Restricted Recipient

External Recipients

The External Recipients MailTip is displayed if the sender adds a recipient that's external, or adds a distribution group that contains external recipients. This MailTip informs senders if a message they're composing will leave the organization, helping them make the correct decisions about wording, tone, and content. By default, this MailTip is turned off. You can turn it on using the Set-OrganizationConfig cmdlet. For details, see Configure Organizational Settings for MailTips. If part of your user mailboxes are hosted on Exchange Online and you're in coexistence with an Exchange Online scenario, the setting on the remote domain object that represents the remote part of your organization has a direct effect on how this MailTip is processed. If the remote domain is configured as an internal domain (by setting the IsInternal parameter on the remote domain object to $true), any recipients in this remote domain will be treated as internal and therefore the External Recipients MailTip won't be displayed. However, if the remote domain isn't configured as an internal domain, the recipients in that domain will be considered external and this MailTip will be displayed when a message is being composed to those recipients. Note: This MailTip isn't evaluated when composing a message to a distribution group in the remote domain.

Large Audience

The Large Audience MailTip is displayed if the sender adds a distribution group that has more than the large audience size configured in your organization. By default, Exchange displays this MailTip for messages to distribution groups that have more than 25 members. For information about configuring the large audience size for your organization, see Configure Organizational Settings for MailTips. The size of distribution groups isn't calculated each time. Instead, the distribution group information is read from the group metrics data. For more information about group metrics, see Understanding Group Metrics. The Moderated Recipient MailTip is displayed if the sender adds a recipient that's moderated. The MailTip indicates which recipient is moderated and informs the sender that this may result in delay of the delivery. If the sender is also the moderator, this MailTip isn't displayed. It's also not displayed if the sender has been explicitly allowed to send messages to the recipient (by adding the sender's name to the Accept Messages Only From list for the recipient). The Reply-All on Bcc MailTip is displayed if the sender receives a Bcc copy of a message and selects Reply to All. When a user selects Reply to All to such a message, the fact that the user received a Bcc of that message is revealed to the rest of the audience to which the message was sent. In almost all cases, this is an undesirable situation, and this MailTip informs the user of this condition. Note: This MailTip is only supported in Microsoft Office Outlook Web App.

Moderated Recipient

Reply-All on Bcc

Oversize Message

The Oversize Message MailTip is displayed if the message the sender is composing is larger than configured message size limits in your organization. The MailTip is displayed if the message size violates one of the following size restrictions: Maximum send size setting on the sender's mailbox Maximum receive size setting on the recipient's mailbox Maximum message size restriction for the organization Maximum Request Length setting (for Outlook Web App only) Note: Due to the complexity of the implementation, the message size limits on the connectors in your organization aren't taken into account. Note: This MailTip isn't displayed in Outlook Web App.

MailTips Architecture
MailTips are implemented as a Web service in Exchange 2010. When a sender is composing a message, the client software makes an Exchange Web service call to the

server running Exchange 2010 with the Client Access server role installed to get the list of MailTips. The Exchange 2010 server responds with the list of MailTips that apply to that message, and the client software displays the MailTips to the sender. The following messaging clients support MailTips:

Outlook Web App Microsoft Outlook 2010 The following actions by the sender trigger MailTips to be evaluated or updated:

Add a recipient Add an attachment Reply or reply to all Open a message, which is already addressed to recipients, from the Drafts folder The client caches the MailTips so removing and adding the same recipient won't result in the client querying the Client Access server again. When the Client Access server is queried, it compiles the list of applicable MailTips and returns them all in one batch. As a result, all MailTips are displayed to the user at the same time and don't arrive one at a time, distracting the sender. The Client Access server uses the following sources to compile MailTips for a specific message:

Active Directory Recipient mailboxes Local group metrics data Each time a sender adds a recipient to a message, a sequence of events occurs to evaluate MailTips, as shown in the following figure.

As shown in the preceding figure:

1. The mail client queries the Web service on the Client Access server for MailTips that apply to the recipients in the message. 2. The Client Access server gathers MailTip data: a. The Client Access server queries Active Directory and reads group metrics data. b. If the recipient is a mailbox that's located on a Mailbox server in the local site, the Client Access server queries the Mailbox server to gather the Automatic Replies and Mailbox Full MailTips. If the recipient's mailbox is in another site, the Client Access server requests MailTips information from the Client Access server in the remote site. c. The Client Access server in the remote site queries the local Mailbox server for MailTip data. d. The remote Client Access server proxies the results back to the requesting Client Access server. 3. The Client Access server returns MailTip data back to the client.

Limits on MailTips
MailTips are subject to the following restrictions:

MailTips aren't supported when working in offline mode with Outlook. When a message is addressed to a distribution group, the MailTips for individual recipients that are members of that distribution group aren't evaluated. However, if any of the members is an external recipient, the External Recipients MailTip is displayed, which shows the sender the number of external recipients in the distribution group. If the message is addressed to more than 200 recipients, individual mailbox MailTips aren't evaluated due to performance reasons. Custom MailTips are limited to 250 characters. If the sender starts composing a message and leaves it open for an extended period of time, the Automatic Replies and Mailbox Full MailTips are evaluated every two hours.

MailTips in Complex Topologies

MailTips that rely on the recipients' mailbox data are evaluated by making a connection to the Mailbox servers that hold those recipients. The Mailbox Full and Automatic Replies MailTips are in this category. For these MailTips, the Client Access server directly queries the Mailbox server using RPC, but only if the recipients are in the same site. For recipients that reside in other sites or forests, this information is gathered via server-to-server Web requests between Client Access servers.

MailTips over Organization Relationships

Microsoft Exchange Server 2010 Service Pack 1 (SP1) allows you to configure organization relationships with Exchange Online or other organizations. Establishing an organization relationship allows you to enhance the user experience when dealing with the other organization with features including sharing free/busy data between the two organizations, configuring secure message flow, and enabling message tracking across the two organizations. For more information about organization relationships, see Understanding Federation. When MailTips are enabled over an organization relationship, the local Client Access servers will proxy the Client Access servers in the remote organization. The behavior is similar to how mailbox-specific MailTips are handled for users in remote Active Directory sites. The one difference is the Client Access servers will proxy all MailTips types over an organization relationship, not just the mailbox-specific MailTips. You have granular control over which MailTip types are returned over an organization relationship in addition to just allowing or preventing returning MailTips. The following two sections explain these settings in detail.

Controlling the MailTips Access Level

There may be many reasons to establish an organization relationship. Depending on the specific situation, you may want to restrict certain types of MailTips. Specifically, you can either allow all MailTips to be returned or only a limited set that would prevent NDRs. You can configure this setting with the MailTipsAccessLevel parameter of the Set-OrganizationRelationship cmdlet. The following table shows which MailTips are returned over the organization relationship.

MailTip Large Audience Automatic Replies

All Yes

Limited No

Yes If the remote domain of the recipient is specified as internal, the internal automatic reply is displayed. Otherwise, the external automatic reply is displayed. Yes

Yes The external automatic reply is displayed.

Moderated Recipient Oversize Message Restricted Recipient Mailbox Full Custom MailTips External Recipients

No

Yes

Yes

Yes

Yes

Yes

No

Yes

No

Yes If the remote domain of the recipient is specified as internal, this MailTip is suppressed. Otherwise, the external MailTip is returned.

Yes If the remote domain of the recipient is specified as internal, this MailTip is suppressed. Otherwise, the external MailTip is returned.

For detailed steps about how to configure MailTips access levels, see Configure Organizational Settings for MailTips.

Controlling the MailTips Access Scope

When you enable MailTips over an organization relationship and set the access level to All, the recipient-specific MailTips, Mailbox Full, Automatic Replies, and custom MailTips, are returned for all users. However, you may only want to allow these MailTips for a specific set of users. For example, if you set up an organization relationship with a partner, you may want to allow these MailTips only for the users that work with that partner. To achieve this, you need to first create a group and add all users for whom you want to share recipient-specific MailTips to that group. You can then specify that group on the organization relationship. After you implement this restriction, your Client Access servers will first verify whether the recipient for whom they received a MailTips query is part of this group. If the recipient is a member of this group, the Client Access servers will proxy back all MailTips including the recipient-specific MailTips. Otherwise they won't include the recipient-specific MailTips in their response. For detailed steps about how to configure MailTips access levels, see Configure Organizational Settings for MailTips.

Performance and Scalability

The following table lists some of the common performance concerns regarding MailTips and how these concerns are addressed.

Common performance concerns for MailTips

Performance concerns Discovering the size of distribution groups and dynamic distribution groups, and whether they include external recipients, seems like an expensive operation. Discovering the delivery restrictions for all recipients in a message with a large number of recipients can be resource- intensive. Mitigation of concern Distribution groups and dynamic distribution groups aren't evaluated when a message is being composed. This information is calculated daily by the group metrics generation service and is distributed to all Client Access servers. For more information, see Understanding Group Metrics. Delivery restrictions aren't evaluated if a message has more than 200 recipients. Also, delivery restrictions aren't evaluated for the members of distribution groups and dynamic distribution groups. This is done only for recipients that are explicitly added to the message. If a user expands a distribution group, delivery restrictions for all members will be evaluated, as long as the total number of recipients doesn't exceed 200. If the requested information isn't returned within 10 seconds, the operation times out. Exchange won't display any new MailTips to the sender after 10 seconds.

It may take a long time to collect information from various sites in complex topologies.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Message Routing

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-04-12 The primary task of Hub Transport and Edge Transport servers in your organization is to route messages received from users and external sources to their ultimate destinations. This topic explains how Microsoft Exchange Server 2010 routes messages in your organization. Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents Overview of Message Routing in Exchange 2010 Routing Components Using Active Directory Sites for Routing Exchange 2010 Routing Tables Receiving Messages for Routing Routing Messages Rerouting and the Unreachable Queue

Overview of Message Routing in Exchange 2010

Routing decisions are made during message categorization. The categorizer is a component of the Microsoft Exchange Transport service that processes all incoming messages and determines what to do with the messages based on information about the intended recipients. The categorizer processes messages in several dependent phases and also uses other components of the Microsoft Exchange Transport service during message processing. After a message is received by an Exchange 2010 transport server, and after the preliminary processing that occurs during SMTP Receive is complete, the message is delivered to the Submission queue. Messages move from the Submission queue through the categorizer in the following phases:

1. Agent processing of submitted messages Some agent processing on the Hub Transport server occurs when the message is received for categorization. The agents that are applied during this phase include the optional Microsoft Forefront Protection for Exchange Server antivirus agent and the Journaling agent. 2. Recipient resolution During this phase, the recipient's e-mail address is resolved to determine whether the recipient has a mailbox in the Exchange organization or an external e-mail address. 3. Routing After information about the recipient is resolved, the routing component of the categorizer determines the ultimate destination for the message and the route to that destination, selects the next segment, or hop, for message relay, and resolves the next hop information to a list of physical servers and IP addresses. 4. Content conversion Before a message is relayed to its next hop, content conversion occurs so that the message is sent in a format that's readable by the recipient. Content conversion transforms e-mail messages from one format to another format for mail flow or storage, such as MAPI to MIME, or UUENCODE to base64 encoded, or for appropriate rendering that's specific to an e-mail client, such as HTML, rich text format (RTF), or plain text. 5. Agent processing of routed messages After the routing decisions for a particular message are made, the Transport Rules agent and the Journaling agent are applied on the Hub Transport server. The Journaling agent is applied both when the message is submitted and when it's routed so that any changes that are made to the message by the Transport Rules agent, for example, when it modifies a delivery address or applies a message-specific journaling requirement, don't bypass the Journaling agent. 6. Message packaging and DSN generation The final categorized message is assembled and moved to a delivery queue. A delivery status notification (DSN) may also be generated during this phase. Messages are next processed by SMTP Send, the store driver, delivery agents, or the foreign gateway connection handler. The component that's used depends on the ultimate destination. A delivery queue is dynamically generated for each hop. The messages are queued in these delivery queues after a routing decision is made. If a route can't be found for a recipient, the messages are queued to the Unreachable queue. The following figure shows how message processing occurs in the different routing phases and how messages are queued for delivery to the next hop destination. Routing context in mail flow

Return to top

Routing Components
To make routing decisions, Exchange 2010 must access configuration information that's stored in Active Directory. On an Edge Transport server, configuration information is stored in and accessed from the Active Directory Lightweight Directory Services (AD LDS) instance on the local server. Microsoft Windows and Exchange 2010 services work together to create mappings of the configuration data. These mappings are cached in routing tables. Exchange 2010 references these tables when it makes routing decisions. The cache is updated when the routing topology changes. The Exchange services that are used during message transport are common to both the Hub Transport server role and the Edge Transport server role. However, the Edge Transport server role doesn't cache information about the Active Directory topology. The following configuration and service components are important to message routing:

Active Directory sites An Active Directory site represents the routing boundary for Hub Transport servers. A Hub Transport server delivers directly to Mailbox servers, distribution group expansion servers, and to source servers for connectors in the local Active Directory site and to Edge Transport servers subscribed to that site. However, a Hub Transport server must relay messages to another Hub Transport server for recipients, expansion servers, and connectors that are located in remote Active Directory sites. The Hub Transport server role must be deployed in every Active Directory site that contains other Exchange 2010 server roles. Active Directory IP site links Active Directory IP site links define logical paths between Active Directory sites. Exchange 2010 references the IP site link objects to determine the least-cost routing path of remote Active Directory sites. Send connectors Send connectors are used for sending messages to other SMTP hosts. The address space configuration on Send connectors are used to make routing decisions. When a message is delivered to an external domain, the routing destination is typically a Send connector. An Exchange organization that accepts messages for more than one e-mail domain may decide to create Send connectors that are dedicated to each address space. For more information about Send connector selection for routing messages to external domains, see External Message Routing. Delivery agents Delivery agents are used to route messages to foreign systems that don't use SMTP protocol for message transfer. The address space and protocol configuration of delivery agents are used when making routing decisions. Foreign connectors Foreign connectors use drop directories to send messages to foreign systems that don't use SMTP protocol for message transfer. Exchange uses the configuration of Foreign connectors when making routing decisions. Routing groups Routing groups represent a routing boundary for Exchange Server 2003. If Exchange 2010 is deployed in an existing Exchange 2003 organization, routing must consider the location of servers within routing groups to deliver a message to a mailbox or a connector that resides on Exchange 2003. To implement compatibility with Exchange 2003, all computers running Exchange 2010 deployed in the organization belong to a single, global routing group. Routing group connectors Routing group connectors define logical paths between Exchange routing groups. If Exchange 2010 is deployed in an existing Exchange 2003 organization, messages are routed between server versions through routing group connectors. When the first Hub Transport server is deployed, the setup process prompts you to create a routing group connector from the global Exchange 2010 routing group to a legacy routing group. For more information about message routing in an environment where more than one version of Exchange is deployed, see Internal Message Routing. Microsoft Exchange Transport service The Microsoft Exchange Transport service is the SMTP provider for Exchange 2010 and controls every component of message processing, from SMTP IN to SMTP OUT. A series of configurable SMTP Receive agents are triggered at various SMTP events. The Microsoft Exchange Transport service enables these agents to process messages as they pass through SMTP transport and perform anti-spam, antivirus, and other tasks before messages are submitted to the categorizer. The Microsoft Exchange Transport service also uses the topology discovery module for Exchange topology discovery. Microsoft Exchange Active Directory Topology service The Microsoft Exchange Active Directory Topology service is responsible for locating the domain controllers and global catalog servers that Exchange 2010 can use to retrieve configuration and recipient data from Active Directory. The Microsoft Exchange Active Directory Topology service is also responsible for keeping Active Directory site affinity for an Exchange 2010 server up to date. Routing tables The routing tables hold the information that the routing component uses to make routing decisions. The routing table is composed of a map of topology components and their relationship to one another. DNS Exchange 2010 uses an enhanced Domain Name System (DNS) client, a component of the Microsoft Exchange Transport service, to resolve the next hop selection to a list of target server names. The standard DNS client is used to resolve that list of server names to IP addresses. Enhanced DNS also provides loadbalancing functionality for Exchange 2010 transport servers by using round robin. SMTP SMTP is used for communication when messages are relayed between SMTP servers. An SMTP server can be a Hub Transport server, Edge Transport server, Exchange 2003 server, or a smart host. A Hub Transport server uses remote procedure call (RPC) to deliver messages directly to Mailbox servers that have the same Active Directory site membership as the Hub Transport server. Return to top

Using Active Directory Sites for Routing

An Active Directory site is a logical configuration component that's based on the physical aspects of the network. The primary purpose for creating an Active Directory site is to define which subnets in the network are connected in a way that optimizes control of Active Directory replication traffic. The Active Directory site represents a routing boundary for Exchange 2010. Computers that have the Hub Transport server role installed make routing decisions based on the Active Directory site topology.

Determining Site Membership

By default, an Active Directory forest contains only one Active Directory site. The default name for this Active Directory site is Default-First-Site-Name. If no other Active Directory sites are created, all domain member computers in the forest are members of Default-First-Site-Name. You don't have to configure a subnet-to-site

association. If additional Active Directory sites are created, you must specify the subnets that are assigned to that Active Directory site. Each Active Directory site is associated with one or more IP subnets. An administrator assigns Active Directory site membership to computers that are configured as domain controllers and global catalog servers. Other domain member computers, such as Exchange servers, are assigned Active Directory site membership automatically when they're configured to use an IP address that's in an IP subnet that's associated with an Active Directory site. Computers that have the same Active Directory site membership are presumed to have good network connectivity. A server is always a member of a single Active Directory site. When an application can determine the Active Directory site membership of the computer where it's installed and of other computers in the forest, and then use that information to control communication flow, it's a site-aware application. When site-aware applications must use the services of another server, such as a domain controller or global catalog server, priority is given to the servers that have the same Active Directory site membership as the computer that's requesting those services. Exchange 2010 is a site-aware application and uses the Active Directory topology for message routing and to communicate with the services that are running on computers that have other Exchange 2010 server roles installed. The Active Directory site isn't only the routing boundary. It's also the service discovery boundary. Determining site membership for a domain member computer depends on a series of DNS queries to compare the local IP address to defined subnets and then determine the appropriate site membership association. To reduce the overhead that's associated with DNS queries, the Exchange 2010 Active Directory schema additions include the msExchServerSite attribute for the Exchange server object. The value of this attribute is the distinguished name of the Active Directory site of an Exchange server. This attribute is a property of each Exchange server object. When site membership affinity is stored as an attribute of the server object, the current topology can be read directly from Active Directory instead of relying on DNS queries and a site membership association is enabled for a non-domain computer, such as a subscribed Edge Transport server. The value for the msExchServerSite attribute is populated and kept up to date by the Microsoft Exchange Active Directory Topology service. When a Windows-based computer starts, the Net Logon service determines site membership for the computer. The Net Logon service uses that information to locate domain controllers that are located in the same Active Directory site as the local computer and then directs authorization and authentication requests to those servers. The Microsoft Exchange Active Directory Topology service uses the DsGetSiteName API call to retrieve the site membership value from the Net Logon service and writes the Active Directory site's distinguished name to the msExchServerSite attribute for the Exchange server object in Active Directory. The following table shows how an organization might define Active Directory sites. In this example, three Active Directory sites are defined, and each Active Directory site is associated with more than one IP subnet. Example of an Active Directory site-to-subnet association

Active Directory site name Site A

Associated IP subnets 192.168.1.0/24 192.168.2.0/24 192.168.3.0/24 192.168.4.0/24 192.168.5.0/24 192.168.6.0/24

Site B

Site C

If a server named HubTransportA has the IP address of 192.168.1.1, it's a member of Site A. By changing the IP address of a server, you may change its site membership. If you change the IP address of HubTransportA to 192.168.2.1, it won't change the server's Active Directory site membership because that subnet is also associated with Site A. However, if you move the server and the IP address changes to 192.168.3.1, the server would be considered a member of Site B. A change in site membership can also occur if you change the association of subnets to Active Directory sites. For example, if you remove the subnet 192.168.3.0 from association with Site B and associate it with Site A, the site membership of a server that has the IP address of 192.168.3.1 also changes to Site A. Whenever a change in site membership occurs, Exchange 2010 must update its configuration data so that the change is considered when Exchange 2010 makes routing decisions. Some latency occurs between the time that a change in an Active Directory site membership occurs and the topology change is fully propagated. The following communication must occur in the following order to propagate topology changes:

1. The change in site membership is written to a domain controller. The updated information replicates between the domain controllers in each Active Directory site in the forest. The time that's required for the change to propagate fully throughout the forest depends on the Active Directory replication topology and schedule as defined by site links. 2. The Net Logon service runs on all Windows-based computers and polls frequently for changes in Active Directory site membership. The Net Logon service polls at five-minute intervals. Therefore, the change is detected by the Net Logon service within five minutes of the local domain controller receiving the update. 3. The Microsoft Exchange Active Directory Topology service queries the Net Logon service at 15-minute intervals to determine the Active Directory site membership of the local Exchange server. If a change is detected, the Microsoft Exchange Active Directory Topology service updates the MsExchServerSite attribute. 4. The changed site attribute value of the Exchange server configuration object is then replicated throughout the organization. The Exchange servers in the organization detect this change. Then the routing tables are updated with the new Active Directory site membership attribute value. Some latency occurs between the time that an Active Directory site membership change takes effect and the time that the updated information is available to another Exchange 2010 server. For more information about how Exchange 2010 handles these types of configuration changes, see "Rerouting and the Unreachable Queue" later in this topic.

IP Site Links
Site links are logical paths between Active Directory sites. A site link object represents a set of sites that can communicate at a uniform cost through a specified intersite transport. Site links don't correspond to the actual path taken by network packets on the physical network. However, the cost assigned to the site link by the administrator typically relates to the underlying network reliability, speed, and available bandwidth. For example, the Active Directory administrator would assign a lower cost to a network connection with a speed of 100 megabits per second (Mbps) than to a network connection with a speed of 10 Mbps. By default, all site links are transitive. This means that if Site A has a link to Site B, and Site B has a link to Site C, Site A is transitively linked to Site C. The transitive link between Site A and Site C is also known as a site-link bridge. An Active Directory site link can be configured to use either IP or SMTP as the transport protocol for communication. An SMTP site link is limited in the types of data that can be replicated by using that protocol and is designed to provide a store and forward mechanism for replication between Active Directory sites that don't have

a reliable network link. An IP site link isn't limited in the types of data that can be replicated across it. Exchange 2010 uses only IP site links to determine its routing topology. The cost that's assigned to the IP site link will be considered by the routing component of Exchange 2010 when calculating a routing table. These costs are used to calculate the least-cost routing path to the ultimate destination for a message. Every Active Directory site must be associated with at least one IP site link. There is a single default IP site link named DEFAULTIPSITELINK. When you create an Active Directory site, you must associate that site to an IP site link. You can create additional IP site links to implement the desired topology, or you can associate every Active Directory site to the DEFAULTIPSITELINK. Each Active Directory site that's part of an IP site link can communicate directly with every other site in that link at a uniform cost. In the following figure, four Active Directory sites are configured in the forest. Every site has been associated with the DEFAULTIPSITELINK. Therefore, each Active Directory site communicates directly with every other site by using the same cost metric. More than one communication path is indicated, but only a single IP site link is defined. Full mesh topology with a single IP site link

In the following figure, four Active Directory sites are configured in the forest. In this topology, the administrator has configured IP site links to create a hub-and-spoke topology of Active Directory sites. Each spoke site can communicate directly with the central site, and the spoke sites can communicate with one another by using the transitive IP site links. Hub-and-spoke topology of Active Directory IP site links

It's important to note that Exchange uses site links only when determining the least-cost path, but will always try to deliver messages directly to the destination Hub Transport server. For example, if a user in Site B in the topology shown in the preceding figure sends a message to another user in Site C, the Hub Transport server in Site B will connect directly to the Hub Transport server in Site C. If you want to force messages to go through Site A, you must enable that site as a hub site. For more information about hub sites, see "Implementing Hub Sites" later in this topic. An Active Directory administrator implements the topology that best represents the connectivity and communication requirements of the forest. Because the same topology is used by Exchange 2010, you must make sure that the current topology supports efficient messaging communication. The default cost for a site link is 100. A valid site link cost can be any number from 1 through 99,999. If you specify redundant links, the link with the lowest cost assignment is always preferred. An Exchange organization administrator can assign an Exchange-specific cost to an IP site link. If an Exchange cost is assigned to an IP site link, it will be used by Exchange 2010. Otherwise, the Active Directory cost is used. For more information about how to set an Exchange cost on an IP site link, see "Controlling IP Site Link Costs" later in this topic. An administrator who has membership in the Enterprise Administrators group can create additional IP site links. For more information about Active Directory site configuration, see Designing the Site Topology.

Controlling IP Site Link Costs

Active Directory IP site links costs are based on relative network speed compared to all network connections in the WAN and are designed to produce a reliable and efficient replication topology. Therefore, in most cases, the existing IP site link costs should work well for Exchange 2010 message routing. However, if after documenting the existing Active Directory site and IP site link topology, you verify that the Active Directory IP site link costs and traffic flow patterns aren't optimal for Exchange 2010, you can make adjustments to the costs evaluated by Exchange. Changing the cost assigned to the IP site link by using Active Directory tools would impact the entire environment. Instead, use the Set-AdSiteLink cmdlet in the Exchange Management Shell to assign an Exchange-specific cost to the IP site link. For example, to set a different cost on the IP site link SITELINKAB for message routing purposes, run the following command in the Shell.

Set-AdSiteLink -Identity SITELINKAB -ExchangeCost 25

When an Exchange cost is assigned to an IP site link, the Exchange cost overrides the Active Directory cost for message routing purposes, and routing only considers the Exchange cost when it evaluates the least-cost routing path. Adjusting IP site link costs can be useful when the message routing topology has to diverge from the Active Directory replication topology. Exchange costs can be used to force all message routes to use a hub site. Exchange costs can also be used to control where messages are queued when communication to an Active

Directory site fails. The following figure shows an Active Directory topology with four sites. Topology with Exchange costs configured on IP site links

In the preceding figure, the network connection between Site C and Site D is a low bandwidth connection that's only used for Active Directory replication and shouldn't be used for message routing. However, the Active Directory IP site link costs cause that link to be included in the least-cost routing path from any other Active Directory site to Site D. Therefore, messages are delivered to the Site D queue in Site C. The Exchange administrator prefers that the least-cost routing path include Site B instead so that if Site D is unavailable, the messages will queue at Site B. Configuring a high Exchange cost on the IP site link between Site C and Site D prevents that IP site link from being included in the least-cost routing path to Site D. Exchange 2010 provides support for configuration of a maximum message size limit on an Active Directory IP site link. By default, Exchange 2010 doesn't impose a maximum message size limit on messages that are relayed between Hub Transport servers in different Active Directory sites. If you use the Set-AdSiteLink cmdlet to configure a maximum message size on an Active Directory IP site link, routing generates a non-delivery report (NDR) for any message that has a size larger than the maximum message size limit that's configured on any Active Directory site link in the least-cost routing path. This configuration is useful for restricting the size of messages that are sent to remote Active Directory sites that must communicate over low-bandwidth connections. For more information, see Understanding Message Size Limits.

Implementing Hub Sites

In your Exchange organization, you may have to force all message delivery to be relayed through a particular Active Directory site. In this scenario, connectivity may prevent direct SMTP relay between sites. Therefore, messages must be relayed through an interim site before they're sent to their destination. Because of an Exchange organization's internal policies, an administrator may also want to relay all messages through a particular site. You can use Shell cmdlets to designate an Active Directory site as a hub site. By designating an Active Directory site as a hub site, you cause additional overall overhead because more servers are involved in message delivery. For example, consider a message that's sent from Site A to Site E. If the least-cost routing path is Site A-Site B-Site C-Site D-Site E, and you designate Site C as a hub site, the message is relayed from Site A to Site C and then relayed from Site C to Site E. You use the Set-AdSite cmdlet to specify an Active Directory site as a hub site. Whenever a hub site exists along the least-cost routing path for message delivery, the messages queue and are processed by the Hub Transport servers in the hub site before they're relayed to their ultimate destination. After the least-cost routing path is chosen, routing determines whether there's a hub site along that routing path. If a hub site is configured, messages stop at a Hub Transport server in the hub site before they're relayed to the target destination. If there's more than one hub site along the least-cost routing path, messages stop at each hub site along the routing path. This variation to direct relay routing only is in effect when the hub site is located along the least-cost routing path. The following figure shows the correct use of a hub site. In this diagram, Site B is configured as a hub site. Messages that are relayed from Site A to Site D are relayed to Site B before they're delivered to Site D. Message delivery with a hub site

The following figure shows how IP site link costs affect routing to a hub site. In this scenario, Site B has been designated as a hub site. However, because it doesn't

exist along the least-cost routing path between any other sites, queuing at Site B before delivery to the destination doesn't occur. An Active Directory site is never used as a hub site if it isn't on the least-cost routing path between two other sites. Misconfigured hub site

You can configure any Active Directory site as a hub site. However, for this configuration to work correctly, you must have deployed at least one Hub Transport server in the hub site.

Topology Discovery
The Exchange 2010 topology relies on the Active Directory site topology and doesn't have its own configuration. The Active Directory topology is made available to Exchange 2010 by the following required elements:

The Microsoft Exchange Active Directory Topology service The topology discovery module inside the Microsoft Exchange Transport service The Microsoft Exchange Active Directory Topology service runs on all Exchange 2010 server roles, except the Edge Transport server role. These Exchange 2010 servers use the Microsoft Exchange Active Directory Topology service to discover the domain controllers and global catalog servers that can be used by the Exchange servers to read and write Active Directory data. Exchange 2010 binds to the identified directory servers whenever Exchange has to read from or write to Active Directory. The topology discovery module is part of the Microsoft Exchange Transport service and provides information about the Active Directory topology to Exchange servers. This API discovers the Exchange servers and roles in the organization and determines their relationship to the Active Directory configuration objects. Configuration data is retrieved from Active Directory and then cached so that it can be accessed by the Exchange services that are running on that computer. The topology discovery module performs the following steps to generate an Exchange routing topology:

1. Data is read from Active Directory. All the following objects are retrieved: Active Directory sites. IP site links. All Exchange servers. This includes information about the Exchange 2010 server roles deployed on those servers. 2. The data that's retrieved in step 1 is used to create the initial topology and to begin linking and mapping the related configuration objects. 3. Exchange servers are matched to Active Directory sites by retrieving the site attribute value from the Exchange server object that's stored in Active Directory. 4. Routing tables are updated with the collection of information retrieved. This process makes every Exchange 2010 server aware of the other Exchange servers in the organization and of how close the Exchange servers are to one another. Return to top

Exchange 2010 Routing Tables

When the Microsoft Exchange Transport service starts, it calculates a set of routing tables that's based on the snapshot of information that's retrieved from Active Directory or, on an Edge Transport server, from AD LDS. The configuration information that's stored in AD LDS includes available connectors and accepted domains, but doesn't include topology data. The routing component refers to the routing tables to determine how to route messages to recipients. When configuration changes are made, the routing tables are rebuilt. The new routing tables are used to route new incoming messages. Messages in remote delivery queues are also rerouted if the routing component determines that they're affected by the configuration changes. For more information about message rerouting, see "Rerouting and the Unreachable Queue" later in this topic. The following configuration data is retrieved from Active Directory and made available to the routing component of Hub Transport servers:

Active Directory sites Active Directory IP site links Exchange servers and their relationship to Active Directory sites SMTP connectors Non-SMTP connectors Note: Non-SMTP connectors include Exchange 2010 delivery agent connectors, Foreign connectors, and in coexistence scenarios, any non-SMTP connectors hosted

by Exchange 2003. Routing groups Routing group connectors Mailbox stores (private message databases (MDBs)) Public folder stores (public MDBs) Public folder hierarchies Based on this data, the routing component of the Microsoft Exchange Transport service populates routing tables to help streamline routing decisions. The routing table correlates the data to create a topology map. This topology map contains the following elements:

Linked connectors map This map correlates the identifiers of Receive connectors on the local server to the linked Send connector. Server map All Exchange 2010 and Exchange 2007 Hub Transport servers, Edge Transport servers, Mailbox servers, and Exchange 2003 servers in the organization are contained in the server map. This map correlates the distinguished name of each Exchange server to server routing data. This includes the total cost to reach that server. Legacy server map All Exchange Server 2007 Hub Transport servers, Edge Transport servers, Mailbox servers, and Exchange 2003 servers in the organization are contained in the legacy server map. This map correlates the legacy distinguished name of each Exchange server to server routing data. This includes the total cost to reach that server. This map supports store override functionality. Store override functionality is specific to public folders. For more information, see "Routing to Public Folders" in Internal Message Routing. MDB map All MDBs in the organization are contained in the MDB map. This map correlates the distinguished name of each MDB to server routing data. This includes the total cost to reach that server. Active Directory site map This map correlates each Active Directory site to a structure that contains the least-cost routing path from the local site to every other site. The map includes any hub sites along the least-cost routing path. Each routing path hop also identifies all Hub Transport servers in that site that will be used by the enhanced DNS component. Routing groups map This map associates the total cost and first hop routing group connector for the least-cost routing path from the Exchange 2010 routing group to each legacy routing group. Send connectors map This map identifies the Send connectors configured in the organization and the source servers for each connector. The routing tables are built every time that a transport server is started and recalculated when configuration changes are received. Configuration changes can be detected in any of the following ways:

Active Directory change notifications There is a delay between the time that a notification is received and the time that the change is written to the routing tables. This delay lets the routing component batch the changes and process more than one change in a single operation. By default, each notification causes the routing component to delay processing by five seconds. For example, if five notifications are received exactly one second after the previous notification, routing delays processing the change for a total of nine seconds. Configuration reloading caused by service control commands The routing component reloads the configuration data when the Microsoft Exchange Transport service is restarted. Periodic reload to track changes that aren't supported by Active Directory notifications By default, routing will periodically reload the configuration data to make sure that all changes are tracked. The configuration reload occurs at six-hour intervals. The information in the routing tables is logged to routing logs. By default, these logs are located in the C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\Routing folder. A new log is generated every time that the routing tables are calculated. If for some reason the Hub Transport server is unable to contact Active Directory, routing continues to make routing decisions based on the currently cached data, even though that data may not be up to date. For more information, see Understanding Routing Table Logging. Return to top

Receiving Messages for Routing

A message can arrive at a Hub Transport server in any of the following ways:

E-mail is received from an Internet-facing SMTP server for delivery to a recipient in the Exchange organization or to a recipient in an internal relay accepted domain. E-mail is received from another Hub Transport server in the Exchange organization for delivery to a recipient mailbox that's located on a Mailbox server in that Active Directory site. E-mail is received from SMTP clients. These are typically POP3 or IMAP4 users that may exist in your environment. E-mail is received from Pickup and Replay directories on a Hub Transport server. These directories are typically used by Foreign connectors to transmit messages to your Exchange infrastructure. E-mail is retrieved from an Exchange 2010 Mailbox server by the Hub Transport server. E-mail is received from an Exchange 2007 or Exchange 2003 server for delivery to a recipient mailbox that's located on an Exchange 2010 Mailbox server. Processing of all e-mail that's received by a Hub Transport server for categorization begins in the Submission queue.

Receiving Messages from Edge Transport Servers, Other Exchange Hub Transport Servers, and SMTP Clients
In this scenario, messages are received from Edge Transport servers, Hub Transport servers, or other third-party SMTP hosts by using standard SMTP connections. The remote host initiates an SMTP connection and transfers the messages to the Hub Transport server. Hub Transport servers use Receive connectors for accepting incoming SMTP connections. Each Hub Transport server has two Receive connectors created during setup. One of these connectors is used to receive authenticated SMTP connections from other Exchange servers. The second one is used to receive SMTP connections from SMTP clients used by POP3 or IMAP4 users in your organization. These two Receive connectors have different permissions configured that are appropriate for their intended use. To learn more about Receive connectors, see Understanding Receive Connectors. By default, Hub Transport servers don't accept unauthenticated anonymous connections. If you need to enable this functionality, we recommend that you create a separate Receive connector to handle the anonymous connections. For more information, see Allow Anonymous Relay on a Receive Connector.

Collecting Messages from Pickup and Replay Directories

Messaging systems that don't use SMTP as the transfer protocol can be connected to your Exchange organization using Foreign connectors. When a message is sent to an Exchange user from a remote system, the Foreign connector writes that message to a special directory on the Hub Transport server called the Pickup directory.

The Hub Transport server periodically checks the Pickup directory for new messages. When it detects a new message, the Hub Transport server then converts the message to an Exchange e-mail message and routes it as a regular message. To learn more about how the Pickup and Replay directories are used, see Understanding the Pickup and Replay Directories.

Retrieving Messages from a Mailbox Server

In this scenario, the Microsoft Exchange Mail Submission service that runs on Mailbox servers notifies a Hub Transport server that's located in the same Active Directory site that messages are ready for retrieval from a sender's outbox. Each Mailbox server maintains a list of Hub Transport servers that are located in the same Active Directory site. This list of Hub Transport servers is known as the submission server list. The server discovery process repeats every ten minutes to keep the list up to date. If more than one Hub Transport server is located in the same Active Directory site as the Mailbox server that's submitting a notification that mail is ready for retrieval, the following process is used to select the server:

If the local Mailbox server is also running the Hub Transport server role and it is not participating in a database availability group (DAG), the local server is notified. If the local Microsoft Exchange Transport service isn't running or the local Hub Transport server can't process new mail submissions because of back pressure, another available Hub Transport server is notified. For more information about back pressure, see Understanding Back Pressure. If the local Mailbox server is also running the Hub Transport server role and is also participating in a DAG, it first tries to notify any Hub Transport server in the site before notifying the local Hub Transport server. This is done to avoid having redundant copies of messages on the same server hardware. To learn more about coexisting Mailbox and Hub Transport server roles when using DAGs, see Hub Transport and Mailbox Server Roles Coexistence When Using DAGs. If the local Mailbox server isn't running the Hub Transport server role, notifications are load balanced among Hub Transport servers by using round robin. If the selected Hub Transport server can't be contacted, the Microsoft Exchange Mail Submission service fails over to a different Hub Transport server in the same Active Directory site. The failing server is marked as inactive, and the next Hub Transport server in the submission server list is selected. If no Hub Transport servers in the local Active Directory site are available, the submission server list is empty. In this case, an event is logged and mail submission notifications are temporarily stopped. Hub Transport servers that are marked as inactive are retried after five minutes. By default, the Microsoft Exchange Mail Submission service load balances notification events across the Hub Transport servers in a site so that each Hub Transport server receives an equal distribution of notification events to process. In some circumstances, providing an equal distribution may not be an optimal solution. Not all Hub Transport servers have the same capacity, and some messages require additional processing. For example, a message that has a large attachment or many recipients takes longer for a Hub Transport server to process than a small message that's addressed to only one recipient. If you want to create a static list of Hub Transport servers that a Mailbox server should notify, you can use the Set-MailboxServer cmdlet in the Shell. Use the SubmissionServerOverrideList parameter to specify a list of Hub Transport servers that the local Mailbox server will notify when it has mail for retrieval. For more information about how to configure this setting, see Set-MailboxServer. After a Hub Transport server receives a mail submission notification from a Mailbox server, it uses the store driver to retrieve the message from the mailbox database and put it in the Submission queue on the Hub Transport server. The transfer of the message from the Mailbox server to the Hub Transport server happens by using Exchange RPC.

Receiving Messages from Legacy Exchange Servers

Due to the changes made to the Exchange Server Object (XSO) model in Exchange 2010, Exchange 2010 Hub Transport servers can't pick up messages from and deliver messages to Exchange 2007 Mailbox servers. Similarly Exchange 2007 Hub Transport servers can't communicate with Exchange 2010 Mailbox servers. All messages sent from Exchange 2007 recipients are first picked up from the Mailbox servers by Exchange 2007 Hub Transport servers and are then relayed to Exchange 2010 Hub Transport servers. To learn more about message routing when coexisting with Exchange 2007, see Upgrade from Exchange 2007 Transport. As opposed to Active Directory sites, Exchange 2003 uses routing groups to route messages. Routing groups are connected to each other using routing group connectors. To support coexistence between these two routing topologies, all Exchange 2010 servers are automatically added to a single routing group when Exchange 2010 is installed in an Exchange 2003 organization. All messages that originate on Exchange 2003 mailboxes are delivered to the Exchange 2010 environment through the routing group connectors between the Exchange 2010 routing group and the Exchange 2003 routing groups. To learn more about message routing when coexisting with Exchange 2003, see Upgrade from Exchange 2003 Transport. Return to top

Routing Messages
After a Hub Transport server or an Edge Transport server receives a message, it determines the ultimate destination and uses the Exchange topology and connector configurations to determine the least-cost routing path. After the routing path is determined, the message is delivered to the next hop on the routing path. Although this topic explains how Exchange makes routing decisions in general, the following two topics provide additional information about specific routing scenarios. The internal message routing topic discusses message delivery to Mailbox servers, public folders, and legacy servers. The external message routing topic discusses routing messages to recipients that are outside your Exchange organization. The topic also discusses the roles of Send connectors, delivery agent connectors, and Foreign connectors.

Internal Message Routing External Message Routing

Determining the Ultimate Destination

The previous section described the various sources from which a Hub Transport server can receive messages. When a message is received by a Hub Transport server, the message must be categorized. The first phase of message categorization is recipient resolution. After the recipient has been resolved, the ultimate destination can be determined. The next phase, routing, determines how to best reach that destination. A single, deterministic route is selected. That route isn't recalculated unless the routing configuration changes. From the perspective of the sending server, each delivery queue represents the destination for a particular message. When the Hub Transport server or Edge Transport server selects the destination for a message, the destination is stamped on the recipient as the NextHopSolutionKey attribute. If a single message is being sent to more than one recipient, each recipient has the NextHopSolutionKey attribute. The receiving server also performs message categorization and queues the

message for delivery. After a message is queued, you can examine the delivery type for a particular queue to determine whether a message will be relayed again when it reaches the next hop destination. The destination for a message can be classified as one of the following delivery types:

DNS connector delivery The messages are queued for delivery to an external recipient by using an SMTP Send connector for which the local server is a source server. The connector is configured to use DNS to resolve the recipient addresses. Smart host connector delivery The messages are queued for delivery to an external recipient by using an SMTP Send connector for which the local server is a source server. The connector is configured to use a smart host for delivery. SMTP relay in an Active Directory site to an Edge Transport server The messages are queued for delivery to an external recipient by using an SMTP Send connector for which the source server is an Edge Transport server that's subscribed to the local Active Directory site. SMTP relay in an Active Directory site to a Hub Transport server The messages are queued for delivery to a Hub Transport server that's located in the same Active Directory site as the local server. The destination server can be an Exchange 2007 Hub Transport server, the source server for a Send connector, a delivery agent connector or Foreign connector, the source server of a routing group connector, or a distribution group expansion server. SMTP relay to a remote Active Directory site The messages are queued for delivery to a Hub Transport server that's located in a remote Active Directory site. The ultimate destination server in the remote Active Directory site can be any of the following: The source server for a connector that's configured to transport messages for external recipients The source server for a routing group connector A distribution group expansion server A Mailbox server that's located in the remote Active Directory site The messages are delivered to one of the Hub Transport servers in the destination site. The receiving server relays the message within the Active Directory site if it's necessary. SMTP relay to a legacy routing group The messages are queued for delivery to the first hop routing group connector used to reach an Exchange 2003 routing group. The ultimate destination server can be any of the following: The source server for a connector An expansion server An Exchange 2003 bridgehead server that delivers messages addressed to mailbox recipients that are located in the routing group MAPI delivery The messages are queued for delivery to a recipient's mailbox, a public folder, or a public folder store that's located on a Mailbox server that's located in the local Active Directory site. Non-SMTP gateway delivery The messages are queued for delivery to an external recipient by using a delivery agent connector or Foreign connector for which the local server is a source server. This delivery type is used only when the messages are being delivered to delivery agent connectors or the Foreign connector drop directory on the local server. Unreachable A route to the recipient couldn't be determined and the messages are located in the Unreachable queue.

Determining the Least-Cost Routing Path

The least-cost routing path to the remote Active Directory site is determined by the calculation of all the costs assigned to the Active Directory IP site links that exist between the two sites. The links are bridged, and a direct connection occurs. Exchange 2010 Hub Transport servers always select a single, deterministic least-cost routing path. Availability of the underlying connection or destination server is never a consideration in routing path selection, and no alternative routing path is considered. The least-cost routing path calculation is used to determine a backoff path when message delivery to the next hop fails. In Exchange 2010, backoff is a mechanism used to deliver messages at an interim hop along the least-cost routing path when direct relay fails for any reason, such as network issues or servers going offline. The routing component tries to deliver messages as close to the destination as possible by backing off, hop by hop, along the least-cost routing path until a connection is made. First, a connection attempt is made to each Hub Transport server in the destination Active Directory site. If no Hub Transport servers in the Active Directory site respond, the least-cost routing path is checked to determine how to start backing off from the delivery site. The goal is to deliver the message as close as possible to the destination and queue it at a Hub Transport server in that Active Directory site. Depending on the individual message routing scenario, the following factors may influence the selection of a least-cost routing path:

Linked connectors If the Receive connector that the message is received on is linked to a Send connector, messages are routed to that Send connector regardless of cost. This configuration always takes precedence. The cost assigned to the IP site links and routing group connectors that must be traversed to reach the destination If more than one routing path exists between a source server and a destination server, the routing path with the lowest aggregate cost is selected. The address space assigned to a Send connector The Send connector with the most specific address space match to the destination is selected. The cost assigned to the address space configured on a Send connector If more than one Send connector is assigned the same address space, the routing component compares the cost assigned to the address space. The Send connector with the lowest cost is selected. Connector scope A connector may be limited to use by Exchange 2010 servers that are located in the same Active Directory site as the source transport servers for the connector. In earlier versions of Exchange, the connector scope could be limited to servers that have the same routing group membership. Message size restrictions The message size constraint specified on a connector must be larger than the size of the message being routed. Connectors with a message size restriction that's less than the size of the message are eliminated from routing consideration. The proximity of the destination to the sending server Routing will prefer the server that's closest, in this order: local server, server in the same Active Directory site, or server in a remote Active Directory site or routing group. The name assigned to an Active Directory site If more than one routing path results in the same aggregate cost, the routing component makes an alphanumeric comparison of the name of the Active Directory sites that precede the target site along each routing path. The routing path where the Active Directory site nearest to the destination is lowest in alphanumeric order is used. The name assigned to a routing group connector If more than one routing path results in the same aggregate cost, the routing component makes an alphanumeric comparison of the name of the routing group connectors that come before the target destination along each routing path. The routing path where the routing group connector nearest to the destination is lowest in alphanumeric order is used. The connector state The Exchange 2010 routing component only considers enabled connectors when it calculates the routing path. However, earlier versions of Exchange don't consider connector state. The following logic is used to select the routing path:

1. First, calculate the least-cost routing path by adding the cost of the IP site links and of any routing group connectors that must be traversed to reach the destination. If the destination is a connector, the cost assigned to the address space is added to the cost to reach the selected connector. If multiple routing paths are possible, only the routing path with the lowest aggregate cost is used. 2. If more than one routing path has the same aggregate cost, the number of hops in each path is evaluated and the routing path with the least number of hops is used. 3. If more than one routing path is still available, the name assigned to the Active Directory sites or routing group connectors before the destination are considered. The routing path where the Active Directory site nearest the destination is lowest in alphanumeric order is used. If the site nearest the destination is the same for all routing paths being evaluated, an earlier site name is considered. The following figure shows the routing topology for an Exchange organization. This topology is used in the following examples to demonstrate the logic used by the

routing algorithm to select the least-cost routing path. Exchange 2010 routing topology

Example 1 A message that's being relayed from Site A to Site D can follow two possible routing paths: Site A-Site B-Site D and Site A-Site C-Site D. The costs assigned to the IP site links in each routing path are added to determine the total cost to route the message. In this example, the routing path Site A-Site B-Site D has an aggregate cost of 20. The routing path Site A-Site C-Site D has an aggregate cost of 10. Routing selects path Site A-Site C-Site D. Example 2 A message is being relayed from Site B to Site D. There are three possible routing paths: Site B-Site D with a cost of 15, Site B-Site E-Site C-Site D with a cost of 15, and Site B-Site A-Site C-Site D with a cost of 15. Because more than one routing path results in the same cost, routing selects the routing path Site B-Site D. This has the least number of hops. Example 3 A message is being relayed from Site A to Site E. There are two possible routing paths: Site A-Site B-Site E with a cost of 10, and Site A-Site C-Site E with a cost of 10. Both routing paths have the same cost and same number of hops. The alphanumeric order of the Active Directory sites immediately before Site E is compared. Site B has a lower alphanumeric value than Site C. Therefore, routing selects the routing path Site A-Site B-Site E. After the least-cost routing path has been determined, the Exchange 2010 routing component doesn't consider alternative routing paths.

Next Hop Selection

Exchange 2010 Hub Transport servers don't relay to each Active Directory site along the least-cost routing path. After the routing path is determined, the message is relayed directly from the source server to the next hop. The next hop selection tries to deliver the messages as close as possible to the ultimate destination. Additional intrasite relay may be required to arrive at the ultimate destination. When routing to legacy routing groups, direct relay to the Active Directory site where the source server for the first hop routing group connector resides occurs. After the message is relayed to the legacy environment, standard legacy routing occurs. The following figure shows a simple Exchange topology and illustrates many of the Exchange routing components. Exchange topology and routing components

Using the preceding figure as a reference, a message that's sent from Mailbox1 in Site A, to the external recipient joe@contoso.com is processed as follows:

1. The Microsoft Exchange Mailbox Submission service that's running on Mailbox1 notifies an Exchange 2010 Hub Transport server that's located in the same Active Directory site of the new mail item for transport. 2. Using RPC, the store driver component on an Exchange 2010 Hub Transport server in the same Active Directory site retrieves the message and puts it in the Submission queue on the local server. 3. From the Submission queue, the message moves through categorization. The categorizer first performs recipient resolution and determines that

joe@contoso.com is an external recipient. 4. The routing component selects the best connector through which to route the message and calculates the least-cost routing path to that connector. In this example, a Send connector has the address space *.contoso.com and is the connector selected by the routing component. All the source servers for this Send connector are located in Site B. 5. The routing component determines the next hop required to reach a source server for the Send connector. The Hub Transport server in Site A queues the message for SMTP delivery to Site B. 6. If the receiving server in Site B is a source server for the Send connector, it queues the message for delivery to that Send connector. If the receiving server isn't a source server for the *.contoso.com Send connector, the message is relayed by using SMTP to a Hub Transport server in Site B that's the source server for the connector. The following table provides additional examples of the next hop selection for several recipients based on the topology shown in the preceding figure. It isn't a complete list of all routing possibilities. It simply provides examples that are most common in a topology like the one shown in the preceding figure. Examples of next hop selection in the preceding figure

Receiving server Hub1 Hub1 Hub1 Hub1 Hub1 Hub3 Hub4 Hub4 Hub4 Hub4 Edge1

Ultimate destination Mailbox1 Mailbox2 Mailbox3 Mailbox4 Recipient@fourthcoffee.com Mailbox1 Mailbox1 Mailbox4 Recipient@contoso.com Recipient@fourthcoffee.com Recipient@fourthcoffee.com

Next hop Mailbox1 Hub3 Site B Routing group connector Edge1 Hub1 or Hub2 Site A Site A Contoso SMTP Host Site A Fourth Coffee SMTP Host

Queue delivery type MAPI delivery SMTP relay in an Active Directory site SMTP relay to a remote Active Directory site SMTP relay to a legacy routing group SMTP relay to Edge Transport SMTP relay in an Active Directory site SMTP relay to a remote Active Directory site SMTP relay to a remote Active Directory site Smart host delivery SMTP relay to a remote Active Directory site DNS delivery

After the least-cost routing path has been calculated and the next hop destination has been chosen, Exchange 2010 routing tries to relay the message directly to the destination, unless a hub site is configured along the least-cost routing path.

Queue at Point of Failure

The least-cost routing path calculation is used to determine a backoff path when message delivery to the next hop fails. Exchange 2010 tries to deliver messages as close to the destination as possible by backing off, hop by hop, along the least-cost routing path until a connection is made. This behavior is known as queue at point of failure. When the messages are queued at the point in the delivery path where communication failed, it not only speeds up delivery after the problem is resolved, but it will also help you determine why the message delivery failed. In the topology shown in the following figure, if a message is being delivered from Site A to Site D, the least-cost routing path may be Site A-Site B-Site C-Site D. Delivery will first be tried directly from Site A to Site D. If no Hub Transport server in Site D responds, delivery will be tried to the Hub Transport servers in Site C. This process continues until a Hub Transport server accepts the message. If all intermediate sites are unavailable, the message will be queued at the source site. If the message is queued in Site C, you can start investigating the failure at the Hub Transport servers in Site D or the network connectivity between Site C and Site D. Queue at point of failure

When the message is queued at the point of failure, the queue is put in a retry state and delivery attempts continue based on the message retry intervals until delivery succeeds or the message expires. The queue is automatically resubmitted for categorization again after a default interval of 12 hours. Queues that have a connector as the next hop destination aren't automatically resubmitted unless a configuration change that causes resubmission occurs. For more information, see Message Rerouting and the Unreachable Queue. You can use the Mail Flow Troubleshooter to help diagnose problems with mail flow. This tool is a component of the Microsoft Exchange Troubleshooting Assistant and can be run from the Toolbox of the Exchange Management Console. In more complex topologies, the least-cost routing path between two Active Directory sites can contain many intermediate Active Directory sites. If a network issue occurs somewhere early along the routing path, it may be too inefficient to back off site by site from the end and try to deliver to every one of the intermediate sites. If the routing path is longer than four hops, binary backoff is implemented until four or fewer sites are remaining. Binary backoff means that the next connection attempt is made at the halfway point in the routing path. For example, if the least-cost routing path from Active Directory Site A to Site G is A - B - C - D - E - F - G and the network failure occurs at the link between Site B and Site C, the first connection attempt is made to all Hub Transport servers in Site G. When the connection attempt fails, the next attempt is made to all Hub Transport servers in Site D. This is halfway to Site G. When that connection attempt fails, connection attempts are

made to Site C, and Site B because they're closer than four links to the source site. The message will eventually be queued on a Hub Transport server in Site B until the B-C link connectivity is restored.

Delayed Fan-Out
A single e-mail message can be addressed to more than one recipient. These recipients may have internal mailboxes, or they may be external recipients. To route a single message to more than one recipient, the following steps occur:

1. Recipient resolution Each recipient of the message is resolved to a delivery destination. 2. Routing The least-cost routing path for each recipient is determined. This includes whether a hub site is configured. 3. Message splitting To route the message to recipients that have different delivery locations, the message must be split into multiple copies. After each recipient has been resolved and a routing path to each delivery destination is determined, Exchange 2010 compares the routing path for each recipient. To preserve bandwidth, the bifurcation, or splitting of the message into multiple copies, doesn't occur until a fork in the routing path is encountered. For example, if multiple recipients of a single message share part or all of the least-cost routing path, a single copy of the message is sent until the message reaches the point in the routing path where a fork occurs. When the divergence in routing paths occurs, the message splits to create a separate copy for each recipient. In the following figure, a single message is sent from Site A to recipients in Site C, Site D, and Site E. The least-cost routing path is shared until the message reaches Site B. In this scenario, a single copy of the message that contains all recipients is relayed to Site B. This represents the first fork in the routing path. From Site B, a single message copy is routed to the recipient in Site D, and a single copy is relayed to Site C. In Site C, the message splits again. A copy of the message is delivered to the recipient in Site C. And, a copy of the message is relayed to Site E for delivery to the recipient in that site. Delayed message fan-out

Return to top

Rerouting and the Unreachable Queue

If routing is unable to determine a route for a valid recipient for any reason, the messages are put in the Unreachable queue. Messages in this queue are rerouted when configuration changes are processed and routing tables are recalculated. Messages aren't rerouted in the following scenarios. Instead, an NDR is returned to the sender. The following scenarios result in a message being routed to the Unreachable queue:

The recipient is a non-SMTP address and a matching connector for the address space can't be found. The message doesn't meet the message size restrictions of any matching connector. Not all configuration changes require resubmission of the messages in the queue. For example, a change to the list of smart hosts for a connector doesn't cause messages to be rerouted. For more information about how messages are rerouted, see Message Rerouting and the Unreachable Queue. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

External Message Routing

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-12-07 Microsoft Exchange Server 2010 handles the routing of messages to external recipients. An external recipient is any message recipient that doesn't have a mailbox in the Exchange organization. Exchange uses Send connectors to route messages to external SMTP domains. If the external recipient isn't on an SMTP messaging system, a Delivery Agent connector or a Foreign connector is used instead. For more information about how Exchange makes routing decisions, see Understanding Message Routing. Looking for management tasks related to message routing? See Managing Message Routing. Contents Send Connectors Delivery Agent Connectors Foreign Connectors Connector Considerations Selecting the Routing Path to an External Recipient Routing Examples

Send Connectors

To route messages to external SMTP domains, you must configure at least one Send connector to relay messages to the Internet. You can configure a Send connector and define the address space as the asterisk (*) wildcard character. The * character indicates that the Send connector can be used to relay messages to all external SMTP addresses. You can also configure Send connectors to relay messages to specific address spaces when Send connector restrictions, such as message size, vary for those external domains. When you configure a Send connector, you must select at least one source server for that Send connector. The source servers are the transport servers associated with that connector to handle message delivery. The source server for a Send connector can be a Hub Transport server, an Edge Transport server, or an Edge server subscribed to an Active Directory site. You can configure more than one source server for a Send connector to provide load balancing and fault tolerance for the address spaces defined on that Send connector. However, each Exchange 2010 source transport server you specify must be in the same Active Directory site. For more information about how to configure your Exchange organization to send and receive Internet e-mail, see Managing Message Routing. When Exchange is processing a message sent to an external recipient, the routing component of the Microsoft Exchange Transport service must select the best Send connector through which to route the message, and then calculate the least cost routing path to reach that Send connector. To learn more about Send connectors, see Understanding Send Connectors. Return to top

Delivery Agent Connectors

Delivery Agent connectors are used to route messages addressed to messaging systems that don't use SMTP. When a message is routed to a Delivery Agent connector, the associated delivery agent performs the content conversion and message delivery. Delivery Agent connectors allow queue management for non-SMTP messages, thereby eliminating the need for storing messages on the file system in the Drop and Pickup directories. For more information, see Understanding Delivery Agents. Return to top

Foreign Connectors
Foreign connectors are used to send messages to third-party messaging systems. Each Foreign connector uses a Drop directory configured on the source Hub Transport servers for receiving messages. The foreign gateway server must be configured to obtain messages from the Drop directory specified for that Foreign connector. For more information about Foreign connectors, see Understanding Foreign Connectors. Return to top

Connector Considerations
Restrictions applied to the connectors may eliminate a specific connector from routing consideration. The following configuration options on connectors can determine whether those connectors are considered when making routing decisions. For more information about configuring connectors, see Managing Connectors.

Connector State
You can disable and enable any connector in your organization. If a connector is disabled, it's not considered when routing messages. For example, if an Exchange 2010 Send connector is disabled, messages aren't routed to that connector. Note: Exchange Server 2003 doesn't detect the disabled state of connectors. Therefore, if Exchange 2003 is deployed in the same organization, it may route to that connector.

Connector Scope
Routing only considers connectors in scope for the sending server. By default, no scope limitation is applied to connectors, and they are available to all Hub Transport servers in the organization. However, you can specify a local scope for a connector. If you configure a connector as scoped, the availability of that connector is limited to Hub Transport servers located in the same Active Directory site as the source servers for the connector. Scoped connectors aren't considered when routing by Hub Transport servers in other Active Directory sites.

Address Space
The address space for a connector specifies the following:

Recipient domains to which this connector routes e-mail Address space type Cost assigned to the address space for that connector When you create a Send connector, the address space type is always configured as SMTP by default. Even though you can also specify a non-SMTP address space for a Send connector, the messages are still sent using SMTP. If you need to use a different transport protocol for transmitting messages to their destination, you must use a Delivery Agent connector or a Foreign connector. When the Microsoft Exchange Transport service selects a connector for routing, it only considers connectors that have a matching address space for the destination domain. You can use the wildcard character * in an address space to indicate all domains, all domains that have a particular top-level domain, such as *.com, or a second-level domain and all its subdomains, such as *.contoso.com. When you configure a connector for a particular domain, e-mail sent to that domain is always routed through that connector. If more than one connector matches the address space for the destination recipient domain, the connector with the more precise address match is selected. For example, if Send connector C1 is configured to have the address space *.contoso.com and Send connector C2 is configured to have the address space northamerica.contoso.com, e-mail addressed to user@europe.subdomain.contoso.com is routed to Send connector C1 and e-mail addressed to user@northamerica.contoso.com is routed to Send connector C2. Even though the latter address matches the address spaces on both connectors, the address space of C2 is a better match.

Message Size Restrictions

A message size restriction on a connector may also remove that connector from consideration during routing path selection if the message being routed is larger than the size restriction configured on that Send connector.

Cost
Connector cost is used to set selection priority when more than one connector is configured for the same address space. During routing, when the connector selection is made, the lowest cost routing path to the destination is selected. By adjusting connector costs, you can control the preferred routing path for mail flow in your organization and to the Internet. When you create a connector, the default cost is set to 1. Return to top

Selecting the Routing Path to an External Recipient

When a message is sent to an external recipient, Exchange 2010 will always select a single connector through which to send the message. The selected connector must meet the message size constraints. After Exchange 2010 has eliminated all connectors whose message size restrictions are less than the size of the message being routed, routing applies the following criteria to determine which connector it will select:

1. From the list of all the connectors configured in the Exchange organization, Exchange narrows the list to connectors that satisfy all the following criteria: In the scope for the local server Enabled With an address space that matches the recipient's e-mail domain 2. From the resulting list, Exchange selects the connector with the most specific address space match. If more than one connector meets the address space match criteria, Exchange 2010 routing evaluates the following criteria to select a connector:

1. Connector cost The cost of the connector is the sum of the cost assigned to all the IP site links between the source Active Directory site and the Active Directory site that contains the source servers for the connector, and the cost assigned to the connector. The connector with the lowest aggregate cost is selected. If more than one connector has the same cost, the selection process continues to the next step. 2. Proximity The source server that has the closest proximity to the routing server is selected. This means that the local server is chosen over another Hub

Transport server in the same Active Directory site, and a server in the local Active Directory site is chosen over a source server in a remote Active Directory site. If more than one connector matches the criteria, the selection process continues to the next step. 3. Alphanumerically lower connector name If more than one routing path has the same cost and proximity, the connector with the name that has the lowest alphanumeric value is selected.

Routing Path Selection When Coexisting with Exchange 2003

In a coexistence scenario, the selection varies slightly depending on whether the source server for the selected connector is an Exchange 2010 or Exchange 2003 server. If more than one connector meets the address space match criteria, and they are all are hosted on servers running Exchange 2003, the following selection method is used:

1. Connector cost The cost of the connector is the sum of the cost assigned to all the routing group connectors between the routing server and the routing group that contains the source servers for the connector and the cost assigned to the connector. 2. Alphanumerically lower connector name If more than one routing path has the same cost and proximity, the connector with the name that has the lowest alphanumeric value is selected. If more than one connector meets the address space match criteria, and they are spread across Exchange 2010 and Exchange 2003, Exchange 2010 will always prefer Exchange 2010 connectors. When a connector is selected, if there are legacy servers listed as source servers as well as Exchange 2010 servers, messages are routed to the Exchange 2010 servers. When all things are equal, Exchange 2010 will always route the messages to other Exchange 2010 servers. After a connector is selected by using the previous criteria, there may be more than one routing path to reach the Active Directory site where the source server for the selected connector is located. In this case, the lowest cost routing path to the connector is calculated by using the logic used for intra-organizational routing. For more information, see Internal Message Routing.

Handling Messages That Can't Be Routed

If no connector satisfies all criteria required to select a connector according to the logic described earlier, one of the following actions occurs:

If there is no matching connector for an SMTP address space, the recipient is marked as unreachable and the message is routed to the Unreachable queue. If the message size exceeds the connector size restriction for all connectors, a non-delivery report (NDR) is returned to the sender. If there is no matching connector for a non-SMTP address space, an NDR is returned to the sender. Return to top

Routing Examples
The following examples illustrate how messages are routed to external recipients.

Example 1: Selecting a Connector Based on Address Space Match

In this topology, a message is being routed from Active Directory Site A to the external recipient, john@subdomain.contoso.com. The following figure shows that two connectors can route messages to this address space.

The following table shows the configuration of two Send connectors in an Exchange 2010 topology.

Examples of Send connector configurations

Send connector name C1 C2 Address space *.contoso.com subdomain.contoso.com Connector cost 1 10 Source servers Hub Transport servers in Active Directory Site A Hub Transport servers in Active Directory Site B Message size restrictions None None

In this scenario, the message is routed by using C2 because the most specific address space match is chosen. C1 has a lower routing cost, and the source servers are located in the same site as the Hub Transport server processing the message. However, the address space match takes priority over the other factors.

Example 2: Selecting a Connector Based on Proximity

In this scenario, a message is being routed by a Hub Transport server located in Active Directory Site A to the external recipient, john@subdomain.contoso.com, as shown in the following figure.

The following assumptions apply:

The routing server isn't listed as a source server for any Send connector. The IP site link between Site A and Site B is assigned a cost of 5. Two Send connectors can route messages to the address space. The following table shows the connector configuration.

Alternative Send connector configuration

Send connector name C1 C2 Address space subdomain.contoso.com subdomain.contoso.com Address space cost 15 10 Source servers Hub Transport servers in Active Directory Site A Hub Transport servers in Active Directory Site B Message size restrictions None None

Because both connectors have the same address space match, the connector cost is evaluated next. The cost assigned to connector C2 is added to the cost of the IP site link between Active Directory Site A and Site B, for a combined cost of 15. The source servers for connector C1 are located in the local Active Directory site. Therefore, the IP site link cost to reach the connector is 0, for a total cost of 15. In this scenario, both connectors match the address space equally and have an equal cost. Routing selects connector C1 because it has a closer proximity.

Example 3: Selecting a Connector Based on Exchange Version

In the next example, a message is being relayed from Active Directory Site A to the external recipient, john@contoso.com, as shown in the following figure.

The following assumptions apply:

There are two Send connectors that match the destination address space equally. The source servers for the routing group connector between Exchange 2003 and Exchange 2010 are located in Site A. The routing group connector has a routing cost of 5. The IP site link between Site A and Site B is assigned a cost of 5. The source server for one of the Send connectors is an Exchange 2003 server located in routing group 1. The following table shows the connector configuration.

Connectors configured on different versions of Exchange

Connector name C1 C2 Address space *.contoso.com *.contoso.com Address space cost 10 1 Source servers Hub Transport servers in Active Directory Site B Exchange 2003 bridgehead servers in routing group 1 Message size restrictions None None

In this scenario, the aggregate cost of using connector C1 is 15, which is the sum of the IP site link cost and the Send connector cost. The aggregate cost of using connector C2 is 6, which is the sum of the routing group connector cost and the Send connector cost. However, even though C1 has a lower routing cost, Exchange will still route the message to the Exchange 2010 connector. Return to top

2010 Microsoft Corporation. All rights reserved.

 2013 Microsoft. All rights reserved.

Message Rerouting and the Unreachable Queue

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-12-07 In Microsoft Exchange Server 2010, there are message routing scenarios where a message that isn't delivered is put in the Unreachable queue or rerouted. The decision to put a message in the Unreachable queue is made during the routing phase of categorization. If a routing path can't be calculated for a message during the routing phase, the message is sent to the Unreachable queue. The decision to reroute a message occurs during the message delivery phase in the SMTP Send connector process. If there are configuration changes that require a message in the queue to be resubmitted, the message is resubmitted for categorization in the message delivery phase and rerouted with the new configuration information. Depending on the type of configuration change, some or all resubmitted messages may be sent to the Unreachable queue or to a different delivery queue. For more information about how the least-cost routing path is computed, see Understanding Message Routing. For more information about how the categorizer works, see Understanding Transport Pipeline. Looking for management tasks related to message routing? See Managing Message Routing.

Message Rerouting
There are two types of message delivery in Exchange:

Local delivery refers to delivery of messages sent to a recipient with a mailbox in the same Active Directory site as the Hub Transport server on which categorization occurred. Remote delivery refers to delivery of messages to recipients in other Active Directory sites of the Exchange organization and to external recipients. Remote delivery queues are the main focus of message rerouting. Remote delivery can be affected by configuration changes in various ways. The routing component of the categorizer tries to detect whether messages in a queue must be rerouted during enhanced Domain Name System (DNS) resolution. During enhanced DNS resolution, routing tries to detect if a queue has to be rerouted. In this phase, the NextHopSolutionKey attribute is resolved to a list of targets. This enables routing to automatically detect any configuration changes that invalidate or modify the NextHopSolutionKey attribute. If routing detects that configuration changes require rerouting of messages in a queue, the messages in the affected queue are resubmitted to the categorizer and the least cost path is recalculated, taking the new configuration changes into account. The store driver, which delivers inbound messages to the Exchange databases, may also reroute messages. It resubmits a message for rerouting if either of the following conditions is true:

The message is in a MAPI delivery queue, and the next hop has been selected, but the message hasn't been delivered. The destination mailbox is moved to another Mailbox server. If a Mailbox server is unavailable when the store driver tries to deliver the messages to that Mailbox server, the store driver puts the message queue in a retry state. If continued attempts to contact the Mailbox server are unsuccessful, when the retry interval expires, all messages in the queue are resubmitted to the categorizer. If a message is located in a non-SMTP gateway delivery queue (a queue being routed to a Delivery Agent connector or a Foreign connector), the foreign gateway connection handler determines whether the configuration change requires rerouting. The foreign gateway connection handler is a component of the Microsoft Exchange Transport service that manages delivery of messages to Delivery Agent connector queues and Foreign connector Drop directories. For example, deleting or disabling a Foreign connector requires rerouting messages to another connector. The following list summarizes the types of configuration changes that affect message routing. Each configuration change is discussed in detail later in this topic:

Invalid next hop The next hop for the message has been deleted or modified, therefore invalidating the previously calculated routing path. The next hop for a message may be an Active Directory site, a connector, or a transport server (either a Hub Transport server or Edge Transport server). Changes to next hop The configuration of the next hop has changed in a way that affects connectivity. For example, changes to the list of Hub Transport servers in the remote Active Directory site cause the next hop connection to be modified. Less preferred routing paths When configuration changes occur along a previously computed routing path, messages already routed are delivered if the routing path is reachable. But new messages are rerouted with the updated configuration changes. Unavailable next hop Network connectivity or target server availability cause the next hop to be unavailable for connectivity. However, the next hop doesn't change. An example is when the Hub Transport servers in an Active Directory site are offline. Additional scenarios where rerouting occurs In some cases, configuration changes may be caused when DNS MX resource record resolution fails for a DNS connector or a smart host connector. Configuration changes that cause message rerouting or delay When specific configuration changes are detected during the message delivery phase, routing actions occur, and messages are rerouted or delivery is delayed.

Invalid Next Hop

Configuration changes can invalidate a previously calculated next hop. In these circumstances, the routing component of the categorizer can detect the configuration change and reroute to compensate for that change.

Delivery to an SMTP Connector on the Local Computer

When a message is being delivered to an SMTP connector on the local computer, the server that received the message for relay to its destination is also the source server for the Send connector through which the message is routed. This kind of delivery occurs when either of the following conditions is true:

The message was received on a linked Receive connector. The recipient has an external address, and a source server for the selected connector is the local computer.

If the Send connector selected by the routing component of the categorizer is deleted or disabled, the configuration change is detected during the message delivery phase. This causes all messages in the queue to be categorized again. If the configuration of the Send connector is changed to remove the local server as a source server of the connector, the configuration change is detected during the message delivery phase, and all messages in the queue are categorized again. A change of the address resolution method of the Send connector causes the queue to be rerouted. A Send connector can be configured to use DNS to resolve MX records and route messages automatically or it can be configured to route all messages through one or more smart hosts. If you change the address resolution of a Send connector, the messages routed through that Send connector are rerouted.

SMTP Relay in an Active Directory Site

SMTP message relay in an Active Directory site occurs in the following scenarios:

The recipient has an external address, and at least one of the source servers for the Send connector is an Exchange 2010 Hub Transport server located in the local Active Directory site. The recipient has an external address, and at least one of the source servers for the Send connector is an Exchange 2010 Edge Transport server subscribed to the local Active Directory site. The recipient's mailbox is located on a server that runs Exchange Server 2007 in the local Active Directory site. The recipient's mailbox is located on a server that runs Exchange Server 2003, and at least one of the source servers for the selected routing group connector is an Exchange 2010 Hub Transport server in the local Active Directory site. The recipient is a distribution group, and the expansion server for the group is an Exchange 2010 Hub Transport server in the local Active Directory site. In the first four scenarios, if the Send connector is deleted or disabled, the configuration change is detected during the message delivery phase, and the queue is resubmitted. In the last scenario, the messages are queued for delivery to an expansion server and the NextHopSolutionKey attribute contains the fully qualified domain name (FQDN) of the expansion server for the distribution group. If the Hub Transport server role is uninstalled from the specified expansion server, that configuration change is detected during the message delivery phase, and the queue is resubmitted.

SMTP Relay to a Remote Active Directory Site

When a message is being delivered to a remote Active Directory site, the next hop is a different Active Directory site than the Hub Transport server processing the message. This kind of delivery occurs in the following scenarios:

The recipient is a resolved user, mailbox database, or public folder, and the destination computer is an Exchange 2010 server in a remote Active Directory site. The recipient is an external address, and the source servers of the Send connector selected for that address are Exchange 2010 servers in a remote Active Directory site. The recipient is an external address, and the source servers of the Foreign connector selected by the routing component of the categorizer are Exchange 2010 servers in a remote Active Directory site. The recipient is a distribution group, and the expansion server is an Exchange 2010 Hub Transport server in a remote Active Directory site. The recipient's mailbox is located on an Exchange 2003 server, and the closest Hub Transport server listed as a source server for the selected routing group connector is located in a remote Active Directory site. In these scenarios, if the remote Active Directory site is deleted, the configuration change is detected during the message delivery phase, and the queue is resubmitted.

SMTP Relay to an Exchange 2003 Server

When a message is being delivered to an Exchange 2003 server, the Exchange 2010 Hub Transport server relays the message through a routing group connector to an Exchange 2003 server. This delivery type occurs in the following scenarios:

The recipient is a resolved user, mailbox database, or public folder located on an Exchange 2003 server. The recipient is an external address, and the source servers for the SMTP connector selected for that address are Exchange 2003 servers. The recipient is an external address, and the source servers for the selected Foreign connector for that address are Exchange 2003 servers. The recipient is a distribution group, and the designated expansion server is an Exchange 2003 server. In these scenarios, if the routing group connector is deleted, the configuration change is detected during the message delivery phase, and the queue is resubmitted.

Changes to Next Hop

In some scenarios, the next hop isn't invalidated. However, it's modified in a way that affects the connection to a next hop target. Such configuration changes are automatically detected during the message delivery phase, and messages are delivered to the new targets. The following types of changes cause an update of the list of next hop targets:

Changes to the target server list of a routing group connector. Changes to the list of Hub Transport servers in the remote Active Directory site. Changes to the list of Hub Transport servers or Edge Transport servers in the local Active Directory site. The introduction of hub sites along a previously calculated routing path. When this change is detected during the message delivery phase, the IP address list returned to the resolve request is adjusted so that the message is sent to the hub site.

Less Preferred Routing Paths

If a configuration change causes the previously calculated routing path to become less preferred or removes the routing path from consideration, the routing path is still reachable and the messages can still be delivered along the previously calculated routing path. The following configuration changes are in this category:

Message size restrictions are added along the routing path. This causes messages that exceed the size limit to be routed along a different routing path. A routing path with better cost or proximity is created. The address space of the connector changes. Other connector-related changes occur, such as the enabling of a connector or modification of the scope for a connector. For example, if a connector whose scope is changed from global to scoped is in the local Active Directory site, the change has no effect. If the connector is in a remote Active Directory site, the change isn't detected during the message delivery phase because the messages are queued to the remote Active Directory site instead of to the connector. As the routing path tries to SMTP-relay to a Mailbox server in the remote Active Directory site, the Mailbox server moves from a remote Active Directory site to a local Active Directory site. The routing path is trying to reach the expansion server for a distribution group when it's no longer an expansion server. In these scenarios, existing messages are delivered along the already calculated routing path. Because the routing path exists and is reachable, messages already routed are unaffected by these configuration changes. However, newly submitted messages are routed by using the updated configuration.

Unavailable Next Hop

In this scenario, a configuration change or network connectivity change doesn't invalidate the next hop to which messages are routed but a configuration change or network connectivity change makes the next hop unavailable. This means that an SMTP connection can't be established to the next hop target for some reason. Possible reasons are as follows:

An attempt is made to establish an SMTP connection with a currently offline Hub Transport server in the local site. A remote Active Directory site has unavailable or offline Hub Transport servers. A remote routing group has unavailable or offline Exchange 2003 bridgehead servers. Remote domains are unavailable because of network connectivity issues. Message delivery failures caused by network connectivity problems aren't detected by the routing component of the categorizer. When an SMTP connection can't be established to the next hop target, the SMTP Send connector retries the queue. The MaxIdleTimeBeforeResubmit parameter, which is located in the EdgeTransport.exe.config file, has a default value of 12 hours. After the configurable retry interval (MaxIdleTimeBeforeResubmit) has expired without successfully establishing a connection, all messages from the delivery queue are resubmitted to the Submission queue. If the connectivity problem still exists, this process is repeated. If the connectivity problem is resolved, messages are delivered as soon as message retry is successful. Or, a configuration change that modifies the next hop destination may resolve the problem. For example, if the problem is caused by all the Hub Transport servers in a destination site being offline, and you move mailboxes to a server in a different site, the next hop would change to the new site. Note: The automatic resubmission from the message delivery queue to the Submission queue only happens for queues that aren't connector queues. Connector queues remain in retry mode until the problem is fixed, or the messages expire and a non-delivery report (NDR) is sent.

Additional Scenarios Where Rerouting Occurs

In addition to the scenarios described earlier in this section, the following scenarios cause messages to be rerouted during the message delivery phase:

DNS MX resolution fails for a DNS connector. If the DNS MX resolution fails because the authoritative host for the MX record wasn't found, an NDR for the messages in the queue is sent immediately. If other types of failures exist, the queue is put into retry mode until a connection is established or the messages expire. DNS MX resolution fails for a smart host connector. The queue is put into retry mode until the messages expire.

Configuration Changes That Cause Message Rerouting or Delay

The following table summarizes the routing actions taken when specific configuration changes are detected during the message delivery phase, and messages are rerouted or delivery is delayed.

Configuration changes that cause message rerouting and delay

Routing scenario Message is routed to a DNS connector configured on the local server. Configuration change The connector is deleted. The connector is changed to a smart host connector. The connector is modified to remove the local server from the source server list. A fatal DNS MX resolution failure occurs. A DNS MX resolution failure that isn't fatal occurs. Routing action The queue is resubmitted. The queue is resubmitted. The queue is resubmitted. Configuration change and routing action

An NDR is sent. The queue is retried until messages

expire. The connector is disabled. The queue is resubmitted.

Message is routed to a smart host connector configured on the local server. Configuration change The connector is deleted. The connector is modified to remove the local server from the source server list. The connector is changed to a DNS connector. The smart host list for the connector is modified. Any DNS MX resolution failure occurs. The connector is disabled. The SMTP server is offline or the destination isn't running an SMTP server. Routing action The queue is resubmitted. The queue is resubmitted.

The queue is resubmitted.

The updated smart hosts list is automatically detected and used during the message delivery phase. The queue is retried until messages expire. The queue is resubmitted. The queue is retried until messages expire.

Message is routed to a connector with a source Hub Transport server or Edge Transport server in the local Active Directory site.

Configuration change The connector is deleted. The source server list for the connector is modified to remove or add Hub Transport or Edge Transport servers in the local Active Directory site. The source server list for the connector is modified to remove all Hub Transport or Edge Transport servers in the local Active Directory site.

Routing action The queue is resubmitted. Changes to source servers in the local site are automatically detected and used during the message delivery phase. The queue is resubmitted.

Message is routed to an expansion server for a distribution group in the local Active Directory site. Configuration change The server is no longer configured for the Hub Transport server role. Routing action The queue is resubmitted.

Message is routed to a transport server in the local Active Directory site. Configuration change The server is offline or the Microsoft Exchange Transport service isn't running. Routing action The queue is resubmitted after an interval.

Message is routed to a remote Active Directory site. Configuration change The remote Active Directory site is deleted. The link to the remote Active Directory site is deleted. Therefore, the site is unreachable from the local site. The list of Hub Transport servers in the remote Active Directory site changes. All Hub Transport servers in the remote Active Directory site are removed. Hub sites are introduced along the routing path of the destination Active Directory site. Routing action The queue is resubmitted. The queue is resubmitted.

Changes are automatically detected and used during the message delivery phase. The queue is resubmitted.

Changes are automatically detected and used during the message delivery phase so that the messages are relayed to the hub site. The queue is resubmitted after an interval.

All Hub Transport servers in the remote

Active Directory site are offline. The remote site is the delayed fan-out point, and all Hub Transport servers in the site are offline. The queue is resubmitted after an interval.

The message is routed to an Exchange 2003 server in a remote routing group. Configuration change The connector is deleted. The source Hub Transport server list for the connector changes to remove the local server from the list. The target bridgehead server list for the connector is changed by removing or adding bridgehead servers in the remote routing group. All Exchange 2003 bridgehead servers in the remote routing groups are offline. Routing action The queue is resubmitted. The queue is resubmitted.

Changes are automatically detected and used during the message delivery phase. The queue is retried until messages expire.

The message is routed to a destination, and there are configuration changes, but the destination is still reachable.

Configuration change The routing path becomes less preferred because a new routing path appears with a reduced cost or closer proximity, or both.

Routing action Changes are automatically detected and used during the message delivery phase. Changes are automatically detected and used during the message delivery phase. Changes are automatically detected and used during the message delivery phase. Changes are automatically detected and used during the message delivery phase. Changes are automatically detected and used during the message delivery phase. Changes are automatically detected and used during the message delivery phase. Changes are automatically detected and used during the message delivery phase.

The routing path is removed for a message because maximum message size restrictions are added along the path.

A previously disabled routing path comes into consideration with a reduced cost because the connector is enabled, put back in scope, or has no message size restrictions. The connector address space changes.

The connector is changed to add local Hub Transport or Edge Transport servers to the source server list.

The message is relayed to a Mailbox server in the remote Active Directory site, while the Mailbox server housing the destination mailbox database is moved to a different site. The message is relayed to a distribution group expansion server when it's no longer an expansion server. (The distribution group's HomeMTA attribute is modified.)

The message is routed by using MAPI delivery to a Mailbox server. Configuration change The mailbox moves to a different Mailbox server. The Mailbox server is offline. Routing action The store driver detects the change and resubmits the messages. The queue is retried and resubmitted after an interval.

The message is routed by using a non-SMTP gateway to a non-SMTP connector configured on the local server.

Configuration change A Foreign connector is deleted. A Foreign connector is modified to remove the local server from the source server list. The connector is disabled. The Drop directory isn't found.

Routing action The queue is resubmitted. The queue is resubmitted.

The queue is resubmitted. The queue is retried until

messages expire.

Unreachable Queue
The Unreachable queue contains messages that can't be routed to their destinations. Typically, an unreachable destination is caused by misspelled e-mail addresses, or configuration changes that have modified the routing path for delivery. Regardless of destination, all messages that have unreachable recipients reside in this queue. The decision to put a message in the Unreachable queue is made during the routing phase of categorization. If a routing path can't be calculated for a message during the routing phase, the message is sent to the Unreachable queue. Messages in the Unreachable queue are rerouted after configuration changes are processed. There is only one Unreachable queue for each Exchange 2010 transport server. During categorization, messages are put in the Unreachable queue when the following conditions are true:

The recipient is a valid Active Directory recipient object. However, a routing path can't be calculated for that recipient. The recipient is an external SMTP address and a matching connector can't be found for the address space. A matching connector may also be ignored by the routing component of the categorizer because it's disabled or configured incorrectly. The recipient is a distribution group. The expansion server for the distribution group is invalid or doesn't have the Hub Transport server role installed. The recipient is an SMTP address recipient of a message received on a Receive connector linked to a Send connector that's ignored by the routing component of the categorizer because it's disabled or configured incorrectly in some way. In the following scenarios, messages aren't put in the Unreachable queue, and NDRs are sent instead:

The routing path can't be calculated for a recipient because constraints, such as message size restrictions, prevent delivery of the message using the single, deterministic route calculated by the categorizer. The recipient is a non-SMTP address and a matching connector can't be found. Or the matching connector is disabled or configured incorrectly. The recipient is a non-SMTP address recipient received on a Receive connector linked to a Send connector that's ignored by the routing component of the categorizer because the Send connector is disabled or configured incorrectly. Messages in the Unreachable queue are resubmitted to the categorizer when the routing tables are rebuilt because of configuration changes. The old routing tables and new routing tables are compared. The Unreachable queue is resubmitted only if the old routing tables and new routing tables aren't the same.

Scenarios Where Messages Are Put in the Unreachable Queue

This section describes some scenarios where messages are put in the Unreachable queue.

Routing group connector between an Exchange 2010 organization and Exchange 2003 organization doesn't exist A routing group connector between the Exchange 2010 routing group and Exchange 2003 routing groups hasn't been configured, or the last routing group connector between the Exchange 2010 routing group and Exchange 2003 routing groups has been removed. No routing group connector exists to provide a routing path to the Exchange 2003 recipients. To resolve this problem, first verify that the routing group connector is missing. If that's the case, you can create a routing group connector. For more information, see Create Additional Routing Group Connectors from Exchange 2010 to Exchange 2003. If a routing group connector does exist, the message is in the Unreachable queue for some other reason. Check the configuration of the routing group connector.

Destination Active Directory site doesn't have Hub Transport servers The destination Active Directory site has no Hub Transport servers. In this scenario, messages to recipients in that site are sent to the Unreachable queue. To resolve this problem, deploy a Hub Transport server in the Active Directory site. For more information, see Overview of the Hub Transport Server Role.

Active Directory site link doesn't exist between two Active Directory sites An Active Directory site link has been removed and as a result, a disconnected Active Directory site contains Exchange 2010 servers. To resolve this problem, create an Active Directory site link by using Active Directory Sites and Services.

Other issues When a message is put in the Unreachable queue, the last error message specifies why the message was placed in the Unreachable queue. If more than one recipient of the same message is routed to the Unreachable queue, but for different reasons, the last error available on each recipient specifies the reason for each. When inconsistencies are found during routing table computation, events are logged in the Application log of Windows Event Viewer. The last error message and these events can help you determine the configuration error and make corrections so that messages in the Unreachable queue can be routed successfully. You can also manually force the messages in queues to be resubmitted. For more information, see Resubmit Messages in Queues.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Internal Message Routing

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-12-07 Internal message delivery involves a routing process that relays e-mail in the following ways:

From a server running Microsoft Exchange Server 2010 that has the Hub Transport server role installed to an Exchange Server 2007 or Exchange 2010 Hub Transport server in a different Active Directory site From an Exchange 2010 Hub Transport server to an Exchange 2010 Mailbox server located in the same Active Directory site From an Exchange 2010 Hub Transport server to a Hub Transport server running Exchange 2007 for delivery to a recipient mailbox located on an Exchange 2007 server From an Exchange 2010 Hub Transport server to a server running Exchange Server 2003 for delivery to a recipient mailbox located on an Exchange 2003 server From an Exchange 2010 Hub Transport server to an Exchange 2010 Mailbox server for delivery to a mail-enabled public folder For more information about how Exchange makes routing decisions, see Understanding Message Routing. Looking for management tasks related to message routing? See Managing Message Routing. Contents Routing Messages for Delivery to Exchange 2010 Servers Routing Messages for Delivery to Exchange 2007 Servers Routing Messages for Delivery to Exchange 2003 Servers Routing to Public Folders

Routing Messages for Delivery to Exchange 2010 Servers

In Exchange 2010, after a message is received by the Hub Transport server, the message is added to the Submission queue. Messages move from the Submission queue through the categorizer. When the message is categorized, a recipient's e-mail address is resolved to an object in Active Directory. This query determines the mailbox associated with that e-mail address and which Mailbox server is hosting that mailbox. After information about the recipient is resolved, the next step is resolving the Mailbox server to an Active Directory site. This Active Directory site information is stamped on the message as the NextHopSolutionKey attribute. The enhanced DNS component of the Microsoft Exchange Transport service accesses the topology information to determine which Hub Transport servers are located in the same site as the destination Mailbox server. A list of Hub Transport servers in the Active Directory site is then referenced to determine where to route the message. If the destination Mailbox server is located in the same site as the querying Hub Transport server, that Hub Transport server queues the message for local delivery. If the destination Mailbox server is located in a different site, the local Hub Transport server queues the message for remote delivery to that Active Directory site. A message queued for local delivery is submitted to the destination mailbox store by the store driver. The message is transferred from the Hub Transport server to the Mailbox server by using an Exchange remote procedure call (RPC). A message queued for delivery to a remote Active Directory site is transferred by using SMTP. Before the message is relayed, the routing component of the categorizer selects the least cost routing path. The method for determining the least-cost routing path is explained in detail in "Determining the Least-Cost Routing Path" in Understanding Message Routing. Return to top

Routing Messages for Delivery to Exchange 2007 Servers

Due to the changes made to the Exchange Server Object (XSO) model in Exchange 2010, Exchange 2010 Hub Transport servers can't pick up messages from and deliver messages to Exchange 2007 Mailbox servers. Similarly, Exchange 2007 Hub Transport servers can't communicate with Exchange 2010 Mailbox servers. As a result, to have both Exchange 2010 and Exchange 2007 in the same Active Directory site, you must maintain both versions of Hub Transport servers in that site. When a Hub Transport server queries Active Directory to determine the Mailbox server hosting the destination mailbox, it also retrieves the version of the Mailbox server. If the Mailbox server is an Exchange 2007 server that's in the same site as the Hub Transport server, the Hub Transport server will relay the message to an Exchange 2007 Hub Transport server in the same Active Directory site. The process of using the version information to make routing decisions is called versioned routing and is explained in detail in Upgrade from Exchange 2007 Transport. If the Mailbox server is in a different Active Directory site, the message is queued for delivery to that remote site and is transferred by using SMTP. Return to top

Routing Messages for Delivery to Exchange 2003 Servers

The routing topology and components of Exchange 2010 differ significantly from those of Exchange 2003 but generally correlate in the following ways:

The Active Directory site in Exchange 2010 correlates to routing groups in Exchange 2003. IP site links in Exchange 2010 correlate to the concept of routing group connectors in Exchange 2003. The functionality of the Hub Transport server role in Exchange 2010 correlates to the functionality of a dedicated bridgehead server in Exchange 2003. However, each Exchange version differs in the method used to determine routing paths. For more information about the routing differences, see Upgrade from Exchange 2003 Transport. A message relayed from a Hub Transport server to an Exchange 2003 server for delivery to a recipient mailbox located on an Exchange 2003 server must be relayed across a routing group connector. All Exchange 2010 servers are associated with a single routing group named Exchange Routing Group (DWBGZMFD01QNBJR) for the purposes of routing to earlier versions of Exchange when Exchange 2010 coexists in the same organization with Exchange 2003. Placement of Exchange 2010 and earlier versions of Exchange in the same routing group isn't supported. Therefore, at least one routing group connector will always separate Exchange 2010 servers from Exchange 2003 servers. When an Exchange 2010 Hub Transport server determines the least-cost routing path to an Exchange 2003 server, the routing component of the Microsoft Exchange Transport service uses the following algorithm to select the least-cost routing path to a computer running Exchange 2003:

1. Examine all possible routing paths across routing group connectors and select the routing path that has the least total cost. 2. If more than one routing path has the same cost, examine all possible routing paths across IP site links to reach the first routing group connector and select the routing path that has the lowest total IP site link cost. 3. If more than one routing path has the same routing group cost and has the same IP site link cost, select the routing path that includes the least number of hops. 4. If more than one routing path has the same routing group cost, the same IP site link cost, and the same number of hops, select the routing path where the name of the last Active Directory site before the destination site has the lowest alphanumeric value. The following figure shows an example of a routing topology where Exchange 2010 and Exchange 2003 coexist.

In this example, a message is being routed from a Hub Transport server in Site A to an Exchange 2003 server located in routing group 2. Two possible routing paths exist to reach routing group 2:

Option 1: From routing group connector A3 at a cost of 10, to routing group connector 2-3 at a cost of 20. This routing path has a total cost of 30. Option 2: From routing group connector C1 at a cost of 10, to routing group connector 1-2 at a cost of 10. This routing path has a total cost of 20. In this example, Option 2 has a lower total routing group connector cost, and the message is routed from the Hub Transport server in Site A, to a Hub Transport server in Site C where it's queued for delivery by using routing group connector C1. The previous example shows how the routing decisions may not result in optimal routing due to the assigned costs on the routing group connectors. To maintain optimal routing, you may need to modify the routing group connector costs you have in your organization. The following figure shows the same topology, but with the cost of routing group connector 2-3 changed to 10.

Again, two possible routing paths are available to reach routing group 2:

Option 1: From routing group connector A3 at a cost of 10, to routing group connector 2-3 at a cost of 10. This routing path has a total cost of 20. Option 2: From routing group connector C1 at a cost of 10, to routing group connector 1-2 at a cost of 10. This routing path has a total cost of 20. In this scenario, both options have the same total routing group connector cost. Routing next evaluates the cost of the IP site links that must be crossed to reach the first routing group connector. From Site A, the IP site link cost to reach routing group connector A3 is zero, and the cost to reach routing group connector C1 is 20. Therefore, the routing path described in Option 1 is selected. Return to top

Routing to Public Folders

Public folders can be mail-enabled in Exchange. Users can send messages to mail-enabled public folders just like any other recipient. When a Hub Transport server receives a message sent to a mail-enabled public folder, the following routing process applies:

1. The categorizer must determine which public folder hierarchy in which the public folder resides. 2. The categorizer looks up the homeMDB attribute for the public folder. The homeMDB attribute identifies the public folder hierarchy where the destination public folder is located. 3. Based on the routing table calculations performed by the Microsoft Exchange Transport service, and described in "Selecting the Destination Public Folder Database" later in this topic, the preferred public folder database is used to determine which public folder hierarchy contains a replica of the destination public folder. If the preferred public folder database is located in the same Active Directory site as the routing Hub Transport server, message processing proceeds as described in step 4 in this section. If the preferred public folder database is located in a remote Active Directory site, the message is relayed to that site by using the least cost routing path. The message categorization process described in step 1 and step 2 earlier in this section are repeated by the Hub Transport server that receives the message in the remote site. If the preferred public folder database is located on an Exchange 2007 or Exchange 2003 server, the message is relayed to the Exchange 2007 Hub Transport server or the Exchange 2003 bridgehead server, and message delivery is determined by the earlier version of Exchange. 4. The Hub Transport server establishes a connection to the store driver on the Mailbox server that contains the preferred public folder database. The public folder database is queried to determine whether content for the public folder is available. The identity of the destination folder is referenced by the legacyExchangeDN attribute, and content availability is determined by the value of the IsContentAvailable attribute. The store driver either accepts the message for delivery, or if the folder contents aren't available locally, the store driver responds with a list of alternative servers that contain a replica of that public folder. The behavior of returning an alternative list of servers is known as store override. The alternative list of servers that contain the public folder replica is listed in the same order provided in client folder referrals, and the top entry is chosen by transport. This referral is provided to routing as the destination to which the message should be routed. For more information about client folder referrals, see Configure Public Folder Referrals. 5. If store override occurs, the Hub Transport server uses the routing table to determine the least cost routing path to the server that contains the preferred public folder replica and routes the message to that destination. 6. The message is delivered to the public folder store.

Selecting the Destination Public Folder Database

Public folders are stored in databases created on Mailbox servers. For efficiency and fault tolerance, you can replicate the content in your public folders to multiple Mailbox servers. Public folder content exists only in Exchange databases configured to have a replica of a specific folder, whereas the hierarchy is replicated to all public folder databases. Content and hierarchy information are replicated separately. Public folder hierarchies are retrieved when routing tables are calculated. The top-level hierarchy object has a list of all the public folder databases to which that hierarchy is replicated. This list of public folder databases is stored as the msExchOwningPFTreeBL attribute in Active Directory. The msExchOwningPFTreeBL attribute always lists the most recently added public folder databases at the top of the list. In Exchange 2010, the preferred public folder hierarchy database is selected by using the following criteria:

1. Ranking by the age of the public folder database By default, public folder databases that have an age threshold of less than two days aren't considered unless the age of all public folder databases is less than the threshold or the age is unknown. 2. Proximity Thelocal server is preferred. If the local server doesn't contain a replica of the public folder database, a server in the same Active Directory site is preferred. If the local Active Directory site doesn't contain a replica of the public folder database, a server in a remote Active Directory site or routing group is selected as the preferred destination. 3. Cost If more than one remote Active Directory site or routing group contains a replica of the public folder database, the server in the Active Directory site or routing group that has the least cost routing path from the local Active Directory site is selected as the preferred destination. If more than one server still meets the criteria, the first server in the replica list returned by Active Directory is selected. After the hierarchy is read, Exchange then determines which public folder databases have replicas of the content. To make sure that correct message delivery can occur to the public folder replica, a preferred public folder database is selected by the routing component of the Microsoft Exchange Transport service from the msExchOwningPFTreeBL list. This selection is made by using the following evaluation process:

1. If only a single instance of a public folder database exists, the server that hosts that database is selected. 2. If the list contains any public folder databases located on servers running Exchange 2007 or Exchange Server 2003, these public folder databases are removed from consideration as the preferred public folder database if a replica also exists on an Exchange 2010 Mailbox server. 3. If more than one Exchange 2010 public folder database is available, the following criteria are used to select a preferred public folder database: a. Ranking by the age of the public folder database The older a public folder database is, the more likely it is to have a replica of the target public folder. Therefore, all public folder databases listed in the msExchOwningPFTreeBL list are ranked according to their date of creation by using a configurable number of days as a baseline. The age ranking for each public folder database can be one of the following, listed from best to worst: More than baseline days old Less than baseline days old Unknown The public folder database that has the best age rating is selected as the preferred public folder database. By default, the baseline age for public folder replicas is two days (48 hours). You can modify this value by editing the PFReplicaAgeThreshold key in the EdgeTransport.exe.config file. This file is located in the %ProgramFiles%\Microsoft\Exchange Server\V14\Bin directory on a computer running Exchange 2010. b. Proximity If more than one public folder database has the best age rating, the Mailbox server that has the best proximity rating is selected. The proximity rating for each public folder database can be one of the following, listed from best to worst: Local server If the local server contains a replica of the public folder database, it's selected as the preferred destination for routing to public folders contained in that hierarchy. Server located in the local Active Directory site If more than one server on the list is located in the local Active Directory site, the first server on the list is selected as the preferred destination for routing to public folders contained in that hierarchy.

 Server located in a remote Active Directory site If the list contains servers from multiple remote Active Directory sites, the server in the Active Directory site that has the least cost routing path from the local Active Directory site is selected as the preferred destination for routing to public folders contained in that hierarchy. If there is more than one server in that site that has a replica of the public folder database, the first server on the list is selected. If more than one remote Active Directory site has the same value for the least cost routing path, the first server on the list is selected. 4. If no public folder database replica is located on an Exchange 2010 Mailbox server, a public folder database located on an Exchange 2007 server is selected as the preferred destination. If there are no Exchange 2007 servers, a public folder database located on an Exchange 2003 computer is selected as the preferred destination for routing to public folders contained in that hierarchy. In either case, the destination public folder database is selected by the age ranking of the public folder database. The age ranking is determined by using the same method as for an Exchange 2010 server. If more than one public folder database has the same age ranking, the first server on the list is selected. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Using Exchange 2010 Transport to Relay Application Server SMTP Traffic

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-01-16 In Microsoft Exchange Server 2010, the Receive connector and load-balancing concepts remain the same as in Exchange Server 2007. Heres a quick review of those concepts. In Exchange 2007, Receive connectors are used to accept incoming messages. By default, when an Exchange Server 2007 Hub Transport server receives an e-mail message via SMTP over TCP port 25, it's processed by the Receive connector named Default Receive connector. In addition, Exchange 2007 automatically load-balances all intra-organization message traffic between Edge Transport, Hub Transport, and Mailbox servers using enhanced DNS. However, this functionality doesn't cover the load-balancing of messages received from non-Exchange sources, such as external mail servers, third-party anti-spam or antivirus solutions, any internal mail servers outside your Exchange organization, line-of-business (LOB) applications, and POP-based or IMAP-based e-mail clients. For more information about how you configure load balancing for messages received from non-Exchange sources, see Understanding SMTP Failover and Load Balancing in Transport. If you place a load-balancing solution in front of your Hub Transport servers, you need to create a separate Receive connector for that purpose and make sure that only traffic processed by that specific connector is subject to load balancing. This is achieved by adding an additional IP address to the Hub Transport server and associating this IP address with the new Receive connector.

Changes in Behavior with Exchange 2010

Exchange 2010 introduces the shadow redundancy feature which provides redundancy for messages for the entire time theyre in transit. With shadow redundancy, the deletion of a message from the transport databases is delayed until the transport server verifies that all of the next hops for that message have completed delivery. Because shadow redundancy is an Exchange 2010 feature, shadow redundancy is only supported by Exchange 2010 servers. If an Exchange 2010 transport server receives messages from a previous version of Exchange Server or a non-Exchange source, the source server cant send the expected XSHADOW command. Therefore, shadow redundancy isnt used. Non-Exchange sources include external mail servers, third-party anti-spam or antivirus solutions, any internal mail servers outside your Exchange organization or line-of-business (LOB) applications the source server. However, when an Exchange 2010 transport server receives a message from a non-Exchange 2010 source, Exchange attempts to achieve shadow redundancy by delaying the acknowledgement to the sending server until it verifies that the message has been successfully delivered to all next hops internally. This way, if the Exchange 2010 server fails, the sending server assumes that the message was never delivered to Exchange and attempts delivery again. The delayed acknowledgement time-out is controlled by the MaxAcknowledgementDelay attribute of each Receive connector. The default value is 30 seconds. For more information about shadow redundancy, see Understanding Shadow Redundancy. Customers who have upgraded from Exchange 2007 to Exchange 2010 and use dedicated Receive connectors for the purpose of relaying messages from sources such as line-of-business (LOB) applications may see a significant decrease in SMTP throughput. This decrease in throughput is because of the default delayed acknowledgement time-out of 30 seconds configured for a Receive connector. To increase the SMTP throughput for the relay Receive connector, we recommend you either lower the time-out value for the delayed acknowledgement attribute or disable it completely. Whether you should lower or disable the time-out value depends on the amount of messages that go through the relay Receive connector. A good approach is to first lower the value and then verify whether SMTP throughput still suffers and, if it does, then disable the feature completely. Important: Although disabling delayed acknowledgements for a Receive connector increases SMTP throughput, it also means that you no longer benefit from the features provided by shadow redundancy. For this reason, we recommend the use of storage hardware redundancy for transport servers for which delayed acknowledgements are disabled.

Use the Shell to configure the maximum acknowledgement delay on a Receive connector
You need to be assigned permissions before you can perform this procedure. To see what permissions you need, see the "Receive connectors" entry in the Transport Permissions topic. Note: You can't use the Exchange Management Console to configure the maximum acknowledgement delay on a Receive connector. This example lowers the time-out value for a Receive connector named SMTP Application relay from 30 to 15 seconds.

Set-ReceiveConnector "SMTP Application relay" -MaxAcknowledgementDelay 15

This example disables delayed acknowledgement on the Receive connector.

Set-ReceiveConnector "SMTP Application relay" -MaxAcknowledgementDelay 0

Important: It isnt possible to disable shadow redundancy for a Receive connector. Instead, you must do this on the Exchange organization level. For detailed syntax and parameter information, see Set-TransportConfig.

Message Throttling Policy Considerations

When relaying application server SMTP traffic through an Exchange 2010 transport server, there are Receive connector specific message throttling policy options that may need to be adjusted, so the overall SMTP throughput doesnt suffer. For example, the MessageRateLimit parameter specifies the maximum number of messages that a Receive connector accepts from a single IP address per minute. On Hub Transport servers, this parameter is set to a value of Unlimited, which means SMTP throughput wont be affected. But, for an Edge Transport server, its set to accept 600 messages per minute. Depending on the relay application server SMTP traffic in your specific environment, you may need to raise this limit. This example raises the message rate limit for a Receive connector named SMTP Application relay from 600 to 2000.

Set-ReceiveConnector "SMTP Application relay" -MessageRateLimit 2000

Another Receive connector specific option that can have an impact on overall SMTP throughput from a relay application server is expressed in the value of the MessageRateSource parameter. With this parameter, you specify how the message submission rate is calculated. It can be set to None, IPAddress, User, or All. By default, the parameter is set to IPAddress, which means the message submission rate is calculated for sending hosts. If this parameter has a negative impact on SMTP throughput from your relay application servers, you should consider setting the value to None. This example disables the MessageRateSource parameter for a Receive connector named SMTP Application relay.

Set-ReceiveConnector "SMTP Application relay" -MessageRateSource None

If youre planning to use a dedicated transport server for relay application server SMTP traffic, you should also consider increasing the maximum number of connections that a Receive connector will serve at the same time from a single IP address. This is done using the MaxInboundConnectionPercentagePerSource parameter. The value for this parameter is expressed as the percentage of available remaining connections on a Receive connector. By default, the value is set to 2 percent. This example changes the value of MaxInboundConnectionPercentagePerSource for a Receive connector named SMTP Application relay from 2 to 30 percent.

Set-ReceiveConnector "SMTP Application relay" - MaxInboundConnectionPercentagePerSource 30

For detailed syntax and parameter information for the above Receive connector specific parameters, see Set-ReceiveConnector.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Message Size Limits

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2013-07-01 You can apply message size limits to individual messages that move through the Microsoft Exchange Server 2010 organization. You can restrict the total size of a message or the size of the individual components of a message, such as the message header, the message attachments, and the number of recipients. You can apply limits globally for the whole Exchange 2010 organization, or specifically for a particular connector or user object. As you plan the message size limits for your Exchange 2010 organization, consider the following questions:

What size limits should I impose on all incoming messages? What size limits should I impose on all outgoing messages? Does my Exchange 2010 organization have a mailbox quota? How do the message size limits that I have chosen relate to the mailbox quota size? Are there users in my Exchange 2010 organization who must send or receive messages that are larger than the specified allowed size? Does my Exchange 2010 network topology include other messaging systems or distinctly separate business units that have different message size limits? This topic provides guidance to help you answer these questions. Looking for management tasks related to Transport servers? See Managing Transport Servers.

Types of Message Size Limits

Following are the basic categories of the size limits available for individual messages:

Message header size limits These limits apply to the total size of all message header fields that are present in a message. The size of the message body or attachments isnt considered. Because the header fields are plain text, the size of the header is determined by the number of characters in each header field and by the total number of header fields. Each character of text consumes 1 byte. Note: Some third-party firewalls or proxy servers apply their own message header size limits. These third-party firewalls or proxy servers may have difficulty processing messages that contain attachment file names that are greater than 50 characters or attachment file names that contain non-US-ASCII characters. Message size limits These limits apply to the total size of a message, which includes the message header, the message body, and any attachments. Message size limits may be imposed on incoming messages or outgoing messages. For internal message flow, Exchange 2010 uses the custom X-MS-ExchangeOrganization-OriginalSize: message header to record the original message size of the message as it enters the Exchange 2010 organization. Whenever the message is checked against the specified message size limits, the lower value of the current message size or the original message size header is used. The size of the message can change because of content conversion, encoding, and agent processing. Attachment size limits These limits apply to the maximum allowed size of a single attachment within a message. The message may contain many attachments that greatly increase the overall size of the message. However, an attachment size limit applies to the size of an individual attachment only. Recipient limits These limits apply to the total number of message recipients. When a message is first composed, the recipients exist in the To:, Cc:, and Bcc: header fields. When the message is submitted for delivery, the message recipients are converted into RCPT TO: entries in the message envelope. A distribution group is counted as a single recipient during message submission.

Scope of Limits
Following are the basic categories for the scope of the limits available for individual messages:

Organizational limits These limits apply to all Exchange 2010 and Exchange 2007 servers that exist in the organization. The specified message limits apply to all Exchange 2010 and Exchange 2007 servers that have the Hub Transport server role installed. On an Edge Transport server, the specified limits apply to the specific server. Global limits Global limits are used when Exchange Server 2003 servers coexist with your Exchange 2010 deployment. The global limits are stored in a different location in Active Directory than the organizational limits and are primarily used by Exchange Server 2003 servers. In an environment where you have both Exchange 2010 and Exchange Server 2003 servers in the same organization, changes that you make to the organizational limits are automatically copied to the corresponding global limits. In Exchange 2010, you can modify the organizational limits by using the Set-TransportConfig cmdlet in the Exchange Management Shell, or by configuring the Hub Transport server organization configuration properties in the Exchange Management Console. Connector limits These limits apply to any messages that use the specified Send connector, Receive connector, Delivery Agent connector, or Foreign connector for message delivery. Connectors are defined on Hub Transport servers or Edge Transport servers. Active Directory site links Hub Transport servers use Active Directory sites and the costs that are assigned to the Active Directory IP site links to determine the least-cost routing path from each Hub Transport server in the organization to every other Hub Transport server in the organization. You can assign specific message size limits to the Active Directory site links in your organization. For example, you may want to apply a lower message size limit to an Active Directory site link that represents a connection to a remote office with a low-bandwidth connection. Any messages that exceed the maximum message size limit on any Active Directory site link included in the least-cost routing path won't be delivered and will generate a delivery status notification (DSN) with a value of 5.3.4. For more information about message routing in Exchange 2010, see Planning to Use Active Directory Sites for Routing Mail. Routing group connectors A routing group connector is used to send and receive messages between Exchange 2010 Hub Transport servers and Exchange Server 2003 bridgehead servers when the organization is running more than one version of Microsoft Exchange. Any messages that exceed the maximum message size limit on any routing group connector won't be delivered. They will generate a DSN with the value of 5.3.4. For more information about routing group connectors, see Upgrade from Exchange 2003 Transport. Server limits These limits apply to a specific Hub Transport server or Edge Transport server. You can set the specified message limits independently on each Hub Transport server or Edge Transport server. If you are using Outlook Web App, the maximum HTTP request size limit setting on the Client Access servers also controls the size of messages that Outlook Web App users can send. For more information, see Configure Maximum Message Size in Outlook Web App. User limits These limits apply to a specific user object, such as a mailbox, contact, distribution group, or public folder.

Organizational Limits
The following table shows the organizational limits, including information about how to configure the limits in the Exchange Management Shell or the Exchange Management Console (EMC).

Organizational limits
Size limit Default value in Exchange 2010 10 MB Shell configuration EMC configuration

Maximum size for messages received

Cmdlet: SetTransportConfig Parameter: MaxReceiveSize

Organization Configuration > Hub Transport > Global Settings > Transport Settings > General tab Organization Configuration > Hub Transport > Global Settings > Transport Settings > General tab Organization Configuration > Hub Transport > Global Settings > Transport Settings > General tab Organization Configuration > Hub Transport > Transport Rules New Transport Rule wizard or Edit Transport Rule wizard

Maximum size for messages sent

10 MB

Cmdlet: SetTransportConfig Parameter: MaxSendSize

Maximum number of recipients per message Note: When a message is first processed by a Hub Transport server, an X-header named X-MSExchange-Organization-OriginalSize: is inserted into the message header. Any Hub Transport servers that are involved in the future delivery of the message will use this value for the message size. Conversion encoding and agent processing can increase the size of the message as it flows through the Exchange organization.

5000

Cmdlet: SetTransportConfig Parameter: MaxRecipientEnvelopeLimit

Maximum attachment size in Transport rules that apply to all Hub Transport servers in the organization

Not configured

Cmdlets: NewTransportRule, SetTransportRule Parameter: AttachmentSizeOver

Global Limits
The following table shows the global limits, including information about where to configure the limits in Exchange System Manager in Exchange Server 2003.

Global limits
Size limit Maximum size for messages received Default value 10240 KB (10 MB) Exchange System Manager configuration

delivContLength in Active Directory Incoming message size in Exchange System Manager Global Settings

Maximum size for messages sent

10240 KB (10 MB)

submissionContLength in Active Directory Outgoing message size in Exchange System Manager Global Settings

Maximum number of recipients per message

5000

msExchRecipLimit in Active Directory Maximum number of recipients in Exchange System Manager Global Settings

Connector Limits
The following table shows the connector limits, including information about how to configure the limits in the Exchange Management Shell or the Exchange

Management Console (EMC).

Connector limits
Size limit Maximum header size through a Receive connector Default value 64 KB Shell configuration Cmdlets: NewReceiveConnector, SetReceiveConnector Parameter: MaxHeaderSize Cmdlets: NewReceiveConnector, SetReceiveConnector Parameter: MaxMessageSize EMC configuration N/A

Maximum message size through a Receive connector

10 MB

Server Configuration > Hub Transport > Receive Connectors > Receive Connector properties > General tab Edge Transport > Receive Connectors > Receive Connector properties > General tab N/A

Maximum number of recipients per message through a Receive connector

200 for the Default Client Receive connector 5,000 for the Default Receive connector on Hub Transport servers 200 for the Default Receive connector on Edge Transport servers Note: If the number of recipients is exceeded for an anonymous sender, the message is accepted for the first 200 recipients. Most SMTP messaging servers detect that a recipient limit is in effect. The SMTP messaging server continues to resend the message in groups of 200 recipients until the message is delivered to all recipients.

Cmdlets: NewReceiveConnector, SetReceiveConnector Parameter: MaxRecipientsPerMessage

Maximum message size through a Send connector

10 MB

Cmdlets: NewSendConnector, SetSendConnector Parameter: MaxMessageSize

Organization Configuration > Hub Transport > Send Connectors > Send Connector properties > General tab Edge Transport > Send Connectors > Send Connector properties > General tab N/A

Maximum message size through an Active Directory site link Maximum message size through a routing group connector Maximum message size through a delivery agent connector

Unlimited

Cmdlet: Set-AdSiteLink Parameter: MaxMessageSize

Unlimited

Cmdlet: SetRoutingGroupConnector Parameter: MaxMessageSize Cmdlets: NewDeliveryAgentConnector, SetDeliveryAgentConnector Parameter: MaxMessageSize Cmdlet: SetForeignConnector Parameter: MaxMessageSize

N/A

Unlimited

N/A

Maximum message size through a foreign connector

Unlimited

N/A

Server Limits
The following table shows the server limits, including information about how to configure the limits in the Exchange Management Shell or the Exchange Management Console (EMC).

Server limits

Size limit

Default value Not configured

Shell configuration

EMC configuration

Transport rule on an Edge Transport server that only applies to the specific server

Cmdlets: New-TransportRule, SetTransportRule Parameter: AttachmentSizeOver Cmdlet: Set-TransportServer Parameter: PickupDirectoryMaxHeaderSize Cmdlet: Set-TransportServer Parameter: PickupDirectoryMaxRecipientsPerMessage

Edge Transport > Transport Rules New Transport Rule wizard or Edit Transport Rule wizard Not applicable

Maximum header size for messages in the pickup directory

64 KB

Maximum number of recipients per message for messages in the pickup directory

100

Not applicable

In addition, you can configure the maximum HTTP request length on your Client Access servers that service Microsoft Office Outlook Web App clients. The value configured for this setting will also affect the message size users can submit. For example, if you set this value lower than other message size limits in your organization, your users will not be able to send large messages using Outlook Web App even though they can send the same message using Outlook. You can configure this setting by modifying the maxRequestLength parameter in the web.config file on your Client Access servers. By default, this file is located in the <Exchange install directory>\V14\ClientAccess\Owa folder. The default value is 30000 KB.

User Limits
The following table shows message size limits that you can configure at the recipient level, including information about how to configure the limits in the Exchange Management Shell or the Exchange Management Console (EMC).

User limits
Size Limit Default value Unlimited Shell configuration EMC configuration

Maximum message size that can be sent by this recipient

Cmdlets: Set-DistributionGroup SetDynamicDistributionGroup Set-Mailbox Set-MailContact Set-MailUser Set-MailPublicFolder Parameter: MaxSendSize

For mailboxes: Recipient Configuration > Mailbox Properties > Mail Flow Settings tab For mail public folders: Public Folder Management Console > Public Folder properties > Mail Flow Settings tab Note: This setting isn't configurable using the EMC for other recipient types.

Maximum message size that can be sent to this recipient

Unlimited

Cmdlets: Set-DistributionGroup SetDynamicDistributionGroup Set-Mailbox Set-MailContact Set-MailUser Set-MailPublicFolder Parameter: MaxReceiveSize Cmdlets: Set-Mailbox, Set-MailUser Parameter: RecipientLimits Cmdlet: Set-MailUser Parameter: MaxRecipientsPerMessage

For all recipient types except Mail Public Folders: Recipient Configuration > Recipient Properties > Mail Flow Settings tab For Mail Public Folders: Public Folder Management Console > Public Folder properties > Mail Flow Settings tab

Maximum number of recipients per message sent by this recipient

Unlimited

N/A

Order of Precedence for Message Size Limits

You can set different message size limits at different levels in the Exchange organization. As a message is routed through your Transport infrastructure, it may be subjected to several different message size restrictions. You should plan your message size restrictions in a way that makes sure that messages in the transport pipeline are rejected as early as possible if they violate message size limits. Generally speaking, you should set more restrictive limits at the points where messages enter your infrastructure. For example, any message size restrictions on your Edge server Receive connectors that receive messages from the Internet should be less than or equal to the message size restrictions you configure for your internal Exchange organization. It would be a waste of system resources for the Edge Transport server to accept and process a message from the Internet that would be rejected by your Hub Transport servers. Make sure that your organization, server, and connector limits are configured in a way that minimizes any unnecessary processing of messages. One exception to this approach is the user limits. User level limits take precedence over other message size restrictions. Therefore, you can configure a user to exceed the default message size limits for your organization. For example, you can allow a specific group of user mailboxes to send larger messages than the rest of the organization by configuring custom send and receive limits for those users. The exceptions for the user limits only apply to message exchanges between authenticated users. If a message is sent to or received by a recipient on the Internet, the organizational limits will be applied. For example, assume that you have an organizational message size restriction of 10 MB, but you have configured the users in your marketing department to send and receive messages up to 50 MB. These users will be able to exchange large messages with each other, but they still wont be able to

receive large messages from Internet users because such messages will be coming from unauthenticated senders.

Messages Exempt from Size Limits

The following list shows the types of messages generated by a Hub Transport server or an Edge Transport server and exempted from all message size limits:

System messages Agent-generated message Delivery status notification (DSN) messages Journal report messages Quarantined messages Important: Even though they are generated by the system, non-delivery reports (NDRs) are not exempt from message size limits. However, these messages are still subject to the organizational value for maximum number of recipients in a message. This value is set by the MaxRecipientEnvelopeLimit parameter that you can configure by using the Set-TransportConfig cmdlet in the Shell.

Differences in Message Size Limits Between Exchange 2003 and Exchange 2010
The primary difference in message size limits between Exchange Server 2003 and Exchange Server 2010 is in the handling of recipient limits. Exchange 2003 treats each member of an expanded distribution list as one recipient. Exchange 2010 treats a distribution group as one recipient. This change was implemented to avoid the partial message delivery scenarios that may occur in Exchange 2003. Partial message delivery occurs in Exchange 2003 if the number of individual recipients and the recipients that are contained within the distribution list exceeds the specified recipient limit. The total number of message recipients isn't known until after distribution list expansion. Message delivery occurs as the distribution list is expanded until the number of recipients reaches the specified limit. The remaining recipients do not receive the message, but at least the sender receives a non-delivery report (NDR) for each unsuccessful delivery. However, if delivery failure reporting is disabled for the distribution list, the remaining recipients wouldn't receive the message, and the sender would not know who did not receive the message.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Message Throttling

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-11-07 This topic explains the message throttling options that are available in Microsoft Exchange Server 2010. It also describes enhancements to the message throttling functionality that are included in Service Pack 1 (SP1) of Microsoft Exchange Server 2010. Message throttling refers to a group of limits that are set on the number of messages and connections that can be processed by a computer that is running Exchange 2010 with either the Hub Transport server role or the Edge Transport server role installed. These limits prevent the accidental or intentional exhaustion of system resources on the transport server. For more information about management tasks related to managing transport servers, see Managing Transport Servers. Contents Message Throttling Scope Message Throttling Options on Transport Servers Message Throttling Option on Send Connectors Message Throttling Options on Receive Connectors Message Throttling Policies

Message Throttling Scope

Message throttling involves a variety of limits on message processing rates, SMTP connection rates, and SMTP session time-out values. These limits work together to protect a Hub Transport server or Edge Transport server from being overwhelmed by accepting and delivering messages. Although a large backlog of messages and connections may be waiting to be processed, the message throttling limits enable the transport server to process the messages and connections in an orderly manner. In addition to message throttling, with Exchange 2010 you can also put size limits on the individual components of messages, such as the number of recipients, the size of the message header, or the size of individual attachments. For more information about message size limits, see Understanding Message Size Limits. Another Exchange 2010 feature that helps avoid overwhelming the system resources of an Exchange 2010 transport server is back pressure. Back pressure is a system resource monitoring feature on Hub Transport servers and Edge Transport servers. When a monitored system resource, such as hard disk utilization or memory utilization, exceeds the specified threshold, the Exchange transport server reduces the rate at which it accepts new connections and messages, and focuses on delivering existing messages. When the utilization of the monitored system resources returns to normal levels, the Exchange transport server slowly increases the rate at which it accepts new connections and then establishes a normal level. For more information, see Understanding Back Pressure.

Message Throttling Enhancements in Exchange 2010 SP1

Exchange 2010 SP1 includes additional features that enhance the message throttling functionality. These enhancements address the following issues that administrators may experience in a messaging environment:

Because more resources are required to send messages that have large attachments or that are sent to multiple recipients, other message delivery operations may experience increased latency. A high rate of mailbox delivery operations may reduce the user interactive mailbox experience. For example, users may experience slow refresh or update times when they access their mailboxes. No centralized method is available to control how a specific user may inadvertently affect the resources of a Transport server. Such an effect may occur if the user sends messages that have high delivery costs in terms of number of recipients or total message size or both. To provide more consistent message throughput and predictable message delivery latency, Exchange 2010 SP1 establishes an accumulated cost for messages. This cost is based on the following criteria:

Message size Number of recipients Frequency of transmission Transport servers that run on Exchange 2010 SP1 track the average delivery cost of messages that are sent by individual users. By using message costs, Exchange 2010 SP1 provides a group of settings that can control the effect that a user or connection has on an Exchange organization. This group of settings is known as a throttling policy. When a user repeatedly sends costly messages, such as messages that have large attachments or messages that are sent to many recipients, the Exchange 2010 SP1-based transport servers use a throttling policy to assign a lower priority to higher-cost messages from the user while continuing to deliver lowercost messages. This new behavior adds a quality of service aspect to the message throttling functionality in Exchange 2010. Note: Message throttling doesnt affect the message priority from a users perspective. Messages still retain the original priority set by the user. For example, messages retain a setting of Important or Urgent, and so on. To support this new functionality, Exchange 2010 SP1 uses the following mechanisms:

Internal prioritization agent This agent is triggered on the OnResolvedMessage event and assigns a lower priority to messages from the same sender that have a high accumulated cost. This cost is measured over a period of one minute and affects messages that have more than 500 P1 and P2 recipients or that are larger than 1 megabyte (MB). Quota-based priority queuing for the MapiDelivery queue type This mechanism causes Exchange to deliver messages in a normal-priority queue more frequently than messages in a low-priority queue. By default, the normal-to-low message ratio is 20:1. However, new messages from a lower priority queue are never delivered sooner than new items from a higher priority queue. For example, consider the following scenario:

1. Twenty normal priority messages are delivered. By default, the next delivered message is a lower priority message. 2. Two new messages are received by the Transport server: One message from a higher priority queue and one message from a lower priority queue. In this scenario, the message from the higher priority queue is delivered first. Then, the message from the lower priority queue is delivered. Throttle concurrent connections based on messaging database health This mechanism monitors the health of the Exchange messaging database (MDB) health and throttles concurrent connections to Exchange transport servers based on an assigned Health Measure value. The MDB is monitored by the Resource Health Monitor API on the Hub Transport server and is assigned a health value from -1 through 100. This value is based on the RPC performance statistics that are included with each RPC response from the Store.exe process. The Resource Health framework uses both the Requests/Second rate performance counter and the Average RPC Latency performance counter to calculate a health value for the database. To help maintain a consistent interactive user experience, Exchange reduces the number of concurrent connections as the health value decreases. The following health value ranges are available: -1: This value indicates that the MDB health state is unknown. This value is assigned when the database starts. In this scenario, the database is considered healthy. 0: This value is assigned if the database is in an unhealthy state. In this state, the database should not be contacted. 1 through 99: These values represent a fair health state. A lower value represents a less healthy database. 100: This value represents a healthy database. The Microsoft Exchange Throttling service in Exchange 2010 SP1 provides the framework for mail flow throttling. This service is installed when you install the Mailbox Server role. The Exchange 2010 Throttling service keeps track of mail flow throttling settings for a specific user and caches the throttling information in memory. Mail flow throttling settings are also known as a budget. Restarting the Exchange 2010 Throttling service also resets mail flow throttling budgets. You can use the throttling policy cmdlets that are available in Exchange 2010 SP1 to configure individual budget settings for a throttling policy. A budget is the amount of access that a user or application may have for a specific setting. A budget represents how many connections a user may have or how much activity a user may be permitted for each one-minute period. For example, a budget may be configured to set the amount of time that a user may spend using a specific feature in Exchange, such as ActiveSync, Outlook Web App, or Exchange Web Services. This threshold is stored in a throttling policy and defines the budget. Time settings for a budget are set as a percentage of one minute. Therefore, a threshold of 100 percent represents 60 seconds. For example, assume that you want to specify Outlook Web App policy settings that limit the amount of time during which a user may run Outlook Web App code on a Client Access server and the amount of time the user may communicate with the Client Access server to 600 milliseconds over a one-minute period. To accomplish this, you need to set the value to 1 percent of one minute (600 milliseconds) for both of the following parameters:

OWAPercentTimeInCAS: 1 OWAPercentTimeInMailboxRPC: 1 A user who has this policy applied has a budget of OWAPercentTimeInCAS of 600 milliseconds and of OWAPercentageTimeInMailboxRPC of 600 milliseconds. In this scenario, when the user is logged into Outlook Web App, the user can run Client Access code for up to 600 milliseconds. After the 600 millisecond-period, the connection is considered over budget and the Exchange server doesnt allow any further Outlook Web App action until one minute after the budget limit is reached. After the one-minute period, the user can run Outlook Web App client access code for another 600 milliseconds. These Exchange 2010 SP1 features, together with the features in the release to manufacturing (RTM) version of Exchange 2010, let an Exchange administrator maintain a consistent user experience without having to deploy more servers than are required to meet the normal workload.

Message Throttling Options on Transport Servers

You can set the message throttling options at the following locations:

On the transport server On a Send connector On a Receive connector You can set all the message throttling options that are available on Hub Transport servers or Edge Transport servers in the Exchange Management Shell. You can also set some of the same options by configuring the transport server properties in the Exchange Management Console (EMC). The following table shows the message throttling options that are available on Hub Transport servers or Edge Transport servers.

Message throttling options on Hub Transport or Edge Transport servers

Source SetTransportServer Parameter MaxConcurrentMailboxDeliveries Description This parameter specifies the maximum number of delivery threads that the Hub Transport server can have open at the same time to deliver messages to mailboxes. The store driver on the Hub Transport server is responsible for delivering messages to and from Mailbox servers. This limit applies to the delivery of messages to any mailboxes in the Exchange organization. The default value of the MaxConcurrentMailboxDeliveries parameter is 20. This parameter specifies the maximum number of delivery threads that the Hub Transport server can have open at the same time to accept messages from mailboxes. The store driver on the Hub Transport server is responsible for delivering messages to and from Mailbox servers. This limit applies to the acceptance of new messages from any mailboxes in the Exchange organization. The default value of the MaxConcurrentMailboxSubmissions parameter is 20. This parameter specifies the maximum rate at which new inbound connections can be opened to the Hub Transport server or the Edge Transport server. These connections are opened to any Receive connectors that exist on the server. The default value for the MaxConnectionRatePerMinute parameter is 1200 connections per minute. This parameter specifies the maximum number of concurrent outbound connections that the Hub Transport server or Edge Transport server can have open at the same time. The outbound connections occur by using the Send connectors that exist on the server. The value that's specified by the MaxOutboundConnections parameter applies to all the Send connectors that exist on the transport server. The default value of the MaxOutboundConnections parameter is 1000. If you enter a value of unlimited, no limit is imposed on the number of outbound connections.

SetTransportServer

MaxConcurrentMailboxSubmissions

SetTransportServer

MaxConnectionRatePerMinute

SetTransportServer or Transport server properties

MaxOutboundConnections

This value can also be configured using the EMC. SetTransportServer or Transport server properties MaxPerDomainOutboundConnections This parameter specifies the maximum number of connections that an Internet-facing Hub Transport server or Edge Transport server can have open to any single remote domain. The outbound connections to remote domains occur by using Send connectors that exist on the server. The default value of the MaxPerDomainOutboundConnections parameter is 20. If you enter a value of unlimited, no limit is imposed on the number of outbound connections per domain. This value can also be configured using the EMC. PickupDirectoryMaxMessagesPerMinute This parameter specifies the rate of message processing for both the Pickup directory and Replay directory. Each directory can independently process message files at the rate that's specified by the PickupDirectoryMaxMessagesPerMinute parameter. By default, the Pickup directory can process 100 messages per minute, and the Replay directory can process 100 messages per minute at the same time. The Pickup directory and the Replay directory scan for new message files once every 5 seconds, or 12 times per minute. This 5-second polling interval isn't configurable. This means the maximum number of messages that can be processed during each polling interval is the value that you assign to the PickupDirectoryMaxMessagesPerMinute parameter divided by 12 (PickupDirectoryMaxMessagesPerMinute/12). By default, a maximum of just over eight messages can be processed during each 5-second polling interval.

SetTransportServer

For more information, see the following topics:

Configure Edge Transport Server Properties Configure Hub Transport Server Properties Set-TransportServer

Message Throttling Option on Send Connectors

The following table shows the message throttling option that's available on Send connectors that are configured in your organization or an Edge Transport server. You must use the Shell to configure this option.

Message throttling option available on Send connectors

Source SetSendConnector Parameter ConnectionInactivityTimeOut Description This parameter specifies the maximum time that an open SMTP connection with a destination messaging server can remain idle before the connection is closed. The default value is 10 minutes.

For more information, see Set-SendConnector.

Message Throttling Options on Receive Connectors

The following table shows the message throttling options that are available on Receive connectors that are configured on a Hub Transport server or an Edge Transport server. You must use the Shell to configure these options.

Message throttling options available on Receive connectors

Source SetReceiveConnector Parameter ConnectionInactivityTimeOut Description This parameter specifies the maximum time that an open SMTP connection with a source messaging server can remain idle before the connection is closed. The default value for a Receive connector that's configured on a Hub Transport server is 5 minutes. The default value for a Receive connector that's configured on an Edge Transport server is 1 minute. This parameter specifies the maximum time that an SMTP connection with a source messaging server can remain open, even if the source messaging server is transmitting data. The default value for a Receive connector that's configured on a Hub Transport server is 10 minutes The default value for a Receive connector that's configured on an Edge Transport server is 5 minutes. The value specified by the ConnectionTimeout parameter must be larger than the value specified by the ConnectionInactivityTimeout parameter. This parameter specifies the maximum number of inbound SMTP connections that this Receive connector allows at the same time. The default value is 5000. This parameter specifies the maximum number of SMTP connections that a Receive connector allows at the same time from a single source messaging server. The value is expressed as the percentage of available remaining connections on a Receive connector. The maximum number of connections that are permitted by the Receive connector is defined by the MaxInboundConnection parameter. The default value of the MaxInboundConnectionPercentagePerSource parameter is 2 percent. This parameter specifies the maximum number of SMTP connections that a Receive connector allows at the same time from a single source messaging server. The default value is 100. This parameter specifies the maximum number of SMTP protocol errors that a Receive connector allows before the Receive connector closes the connection with the source messaging server. The

SetReceiveConnector

ConnectionTimeOut

SetReceiveConnector SetReceiveConnector

MaxInboundConnection

MaxInboundConnectionPercentagePerSource

SetReceiveConnector SetReceiveConnector

MaxInboundConnectionPerSource

MaxProtocolErrors

default value is 5. SetReceiveConnector TarpitInterval This parameter specifies the delay that's used in tarpitting. Tarpitting is the practice of artificially delaying SMTP responses for specific SMTP communication patterns that indicate a directory harvest attack or other unwelcome messages. A directory harvest attack is an attempt to collect valid e-mail addresses from a particular organization to use as a target for unsolicited commercial e-mail. The delay that's specified by the TarpitInterval parameter only applies to anonymous connections. The default value of the TarpitInterval parameter is 5 seconds. For more information, see Understanding Recipient Filtering.

For more information, see Set-ReceiveConnector.

Message Throttling Policies

In Exchange 2010 SP1, each mailbox has a ThrottlingPolicy setting. The default value for this setting is $Null. You can use the Set-Mailbox command together with the ThrottlingPolicy parameter to configure a throttling policy for a mailbox. A default throttling policy exists to provide a default set budget configuration for users who connect to Exchange. To configure customized budget settings for one or more users, create a new throttling policy. Then, apply the policy to the appropriate user or group. Important: We recommend that you do not modify the default throttling policy. You can set all the message throttling options that are available on Mailbox servers in the Exchange Management Shell. The following cmdlets are available to manage throttling policies:

Get-ThrottlingPolicy Remove-ThrottlingPolicy New-ThrottlingPolicy Set-ThrottlingPolicy For more information, see Understanding Client Throttling Policies. You can use the New-ThrottlingPolicy and Set-ThrottlingPolicy cmdlets to configure how much activity a user can perform against Exchange over a specific connection or time period. These settings make up a users budget. You can establish throttling policies to control access to the following Exchange features:

Exchange ActiveSync Exchange Web Services Outlook Web App Unified Messaging IMAP4 POP3 Outlook client connections (MAPI or RPC connections) Mail flow settings PowerShell commands CPU usages For more information about the policy settings available for use with the throttling policy cmdlets, see New-ThrottlingPolicy and Set-ThrottlingPolicy. For more information about how to configure Transport servers, see the following topics:

Configure Edge Transport Server Properties Configure Hub Transport Server Properties Set-TransportServer

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Moderated Transport

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-08-05 Using the moderated transport feature in Microsoft Exchange Server 2010, you can require all e-mail messages sent to specific recipients be approved by moderators. You can configure any type of recipient as a moderated recipient, and Exchange 2010 Hub Transport servers will ensure that all messages sent to those recipients go through an approval process. In any type of organization, you may need to restrict access to specific recipients. The most common scenario is the need to control messages sent to large distribution groups. Depending on your organization's requirements, you may also need to control the messages sent to executive mailboxes or partner contacts. You can use moderated recipients to accomplish these tasks. Note: Previous versions of Exchange don't support moderated recipients. If a message sent to a moderated distribution group is expanded on a Hub Transport server running Exchange Server 2007, it will be delivered to all members of that distribution group, bypassing the moderation process. If you have Exchange 2007 Hub Transport servers in your Exchange 2010 organization, and you want to use moderated distribution groups, you must designate an Exchange 2010 Hub Transport server as the expansion server for the moderated distribution groups. Doing this ensures that all messages sent to the distribution group are moderated. Moderated transport relies on the Exchange 2010 approval framework. For more information about the approval framework, see Understanding Approval Framework. Looking for management tasks related to transport servers? See Managing Transport Servers.

Moderated Transport
The moderated transport application consists of the following components:

Categorizer The transport categorizer initiates the approval process. When the categorizer detects a moderated recipient while processing a message, it reroutes the message to the arbitration mailbox. Store driver The store driver processes the messages that the categorizer marks for moderation. When the store driver encounters such a message, it stores the original message in the arbitration mailbox and sends approval requests to the moderators. When a moderator responds with a decision, the store driver marks that decision on the message that's stored in the arbitration mailbox. If an approved message is submitted again by the Information Assistant, the store driver removes the approval workflow wrappers so the message that's delivered is identical to the original message submitted by the sender. Information Assistant The Information Assistant process monitors the arbitration mailbox. The Information Assistant resubmits any approved messages to the submission queue for delivery to the intended recipients, or it deletes rejected messages. The Information Assistant is also responsible for sending rejection notifications to the sender. In addition, it cleans up the arbitration mailbox by deleting any stale or orphaned messages from the arbitration mailbox. For example, if a moderator simply deletes an approval request instead of making a decision, the corresponding message waiting for approval in the arbitration mailbox needs to be removed by the Information Assistant. Arbitration mailbox The arbitration mailbox is used to store the original message that's awaiting approval. By default, one arbitration mailbox is created for moderated transport during setup. It's used for all moderated recipients. You can add additional arbitration mailboxes for load balancing purposes. If you're using multiple arbitration mailboxes, you need to specify which mailbox to use for each moderated recipient.

Message Flow for Moderated Recipients

When a user sends a message to a recipient for whom message moderation is enabled, the message follows a path to its destination, as shown in the following figure and described in the following steps.

1. 2. 3. 4. 5. 6.

The sender creates a message and sends it to the moderated recipient. The categorizer intercepts the message, marks it for moderation, and then reroutes it to the arbitration mailbox. The store driver stores the message in the arbitration mailbox and sends an approval request to the moderator. The moderator uses the buttons in the approval request to either accept or reject the message. The store driver marks the moderator's decision on the original message stored in the arbitration mailbox. The Information Assistant reads the approval status on the message stored in the arbitration mailbox, and then processes the message depending on the moderator's decision: a. If the moderator has approved the message, the Information Assistant resubmits the message to the submission queue, and the message is delivered to

the recipient. b. If the moderator has rejected the message, the Information Assistant deletes the message from the arbitration mailbox and notifies the sender that the message was rejected. Note: If the moderator doesn't respond to the message within five days, the Information Assistant will delete the message from the arbitration mailbox and notify the sender that their message has expired.

Handling Multiple Moderated Recipients

It's possible to send a message to a group of recipients that includes both moderated recipients and recipients that aren't moderated. In this case, a separate approval process occurs for each moderated recipient. Consider a message that's sent to 12 recipients, one of which is a moderated distribution group. The categorizer splits this message into two messages. One message is delivered immediately to the 11 recipients that aren't moderated, and the second message is submitted to the approval process for the moderated distribution group. If a message is intended for more than one moderated recipient, a separate copy is created for each moderated recipient and is submitted to the approval process. A moderated distribution group may contain other moderated recipients. In this case, after the message to the distribution group is approved, a separate approval process occurs for each moderated recipient that's a member of the distribution group. However, you can also enable the automatic approval of the distribution group members after the message to the moderated distribution group is approved. To do this, you set the BypassNestedModerationEnabled parameter of the moderated distribution group to $true. For more parameter and syntax information, see Set-DistributionGroup.

Bypassing Moderation
Messages from moderators are delivered to the moderated recipient immediately, bypassing the approval process. By definition, a moderator has the authority to determine what messages are appropriate for a moderated recipient. Moderation is also bypassed for owners of distribution groups and dynamic distribution groups. The owner of a distribution group can be responsible for managing the distribution group membership, but may not be able to moderate messages sent to it. For example, the account provisioning staff may be the owners of a distribution group called All Employees, but only specific people in human resources may have moderator rights for the same distribution group.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding the Pickup and Replay Directories

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-10-14 By default, the Pickup and Replay directories exist on every computer running Microsoft Exchange Server 2010 that has the Hub Transport server role or the Edge Transport server role installed. Correctly formatted e-mail message files that you copy to the Pickup or Replay directories are submitted for delivery. The Pickup directory is used by administrators for mail flow testing, or by applications that must create and submit their own messages. The Replay directory receives messages from foreign gateway servers and can also be used to resubmit messages that administrators export from the queues of Exchange 2010 servers. Looking for management tasks related to Pickup and Relay directories? See Managing Connectors. Contents Anatomy of an E-Mail Message File How the Pickup Directory Processes Messages How the Replay Directory Processes Messages Security Considerations for the Pickup and Replay Directories Permissions for the Pickup and Replay Directories

Anatomy of an E-Mail Message File

A standard SMTP e-mail message consists of a message envelope and message content. The message envelope contains information required for transmitting and delivering the message. The message content contains message header fields (collectively called the message header) and the message body. The message envelope is described in RFC 2821, and the message header is described in RFC 2822. When a sender composes an e-mail message and submits it for delivery, the message contains the basic information required to comply with SMTP standards, such as a sender, a recipient, the date and time that the message was composed, an optional subject line, and an optional message body. This information is contained in the message itself and, by definition, is contained in the message header. The sender's messaging server generates a message envelope for the message by using the sender and recipient information found in the message header and transmits the message to the Internet for delivery to the recipient's messaging server. Recipients never see the message envelope, because it's generated by the message transmission process and isn't actually part of the message. Each server involved in the transmission of the message may insert message header fields related to the server's role in delivering the message or other applicationspecific message header fields into the message header. When the recipient opens the message by using an e-mail client, the e-mail client displays some of the more relevant information from the message header, such as the sender, the recipients, and the subject together with the message body. Return to top

How the Pickup Directory Processes Messages

A correctly formatted .eml message file copied to the Pickup directory is processed for submission in the following steps:

1. The Pickup directory is checked for new message files every five seconds. You can't modify this polling interval. You can adjust the rate of message file processing by using the PickupDirectoryMaxMessagesPerMinute parameter on the Set-TransportServer cmdlet. The default value is 100 messages per minute. Files that can't be opened are left in the Pickup directory and are reevaluated at the next poll. 2. Limits put on message files in the Pickup directory, such as the maximum header size and the maximum number of recipients, are checked. By default, the maximum header size is 64 kilobytes (KB), and the maximum number of recipients is 100. You change these limits by using the Set-TransportServer cmdlet. 3. The file is renamed from <filename>.eml to <filename>.tmp. If the <filename>.tmp file already exists, the file is renamed as <filename><datetime>.tmp. If the file renaming fails, an event log error is generated, and the pickup process proceeds to the next file. 4. After the .tmp file is successfully converted into an e-mail message, a delete on close command is issued to the .tmp file. The .tmp file appears to remain in the Pickup directory, but the file can't be opened. 5. After the message is successfully queued for delivery, a close command is issued, and the .tmp file is deleted from the Pickup directory. If the deletion fails, an event log error is generated. If the Microsoft Exchange Transport service is restarted when there are .tmp files in the Pickup directory; all .tmp files are renamed as .eml files and are reprocessed. This could lead to duplicate message transmission.

Requirements for Message Files in the Pickup Directory

A message file copied to the Pickup directory must meet the following requirements for successful delivery:

The message file must be a text file that complies with the basic SMTP message format. MIME message header fields and content are supported. The message file must have an .eml file name extension. At least one e-mail address must exist in the Sender or From message header fields in the message header. If a single e-mail address exists in both the Sender and From fields, the e-mail address in the From field is used as the originator of the message in the message envelope. Only one e-mail address can exist in the Sender field. Multiple e-mail addresses aren't allowed. The Sender field is optional if only one e-mail address exists in the From field. Multiple e-mail addresses are allowed in the From field, but a single e-mail address must also exist in the Sender field. The address in the Sender field is then

used as the originator of the message in the message envelope. At least one e-mail address must exist in the To, Cc, or Bcc fields. A blank line must exist between the message header and the message body. This example shows a plain text message that uses acceptable formatting for the Pickup directory.

To: mary@contoso.com From: bob@fabrikam.com Subject: Message subject This is the body of the message.

MIME content is also supported in Pickup directory message files. MIME defines a broad range of message content that includes languages that can't be represented in 7-bit ASCII text, HTML, and other multimedia content. A complete description of MIME and its requirements is beyond the scope of this topic. This example shows a simple MIME message that uses acceptable formatting for the Pickup directory.

To: mary@contoso.com From: bob@fabrikam.com Subject: Message subject MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit <HTML><BODY> <TABLE> <TR><TD>cell 1</TD><TD>cell 2</TD></TR> <TR><TD>cell 3</TD><TD>cell 4</TD></TR> </TABLE> </BODY></HTML>

Modifications to the Message Header That Are Made to Message Files in the Pickup Directory
The Pickup directory removes any of the following message header fields from the message header:

Received Resent-* Bcc Note: Any e-mail addresses found in the optional Bcc message header fields in the message header are correctly processed. After the Bcc recipients are promoted to invisible message envelope recipients, they are removed from the message header to protect their identity. If a message contains only Bcc recipients, the value of Undisclosed Recipients is added to the To field in the message header. The Pickup directory adds its own Received header field to a message as part of the message submission process. The Received header field is applied in the following format.

Received: from localhost by Pickup with Microsoft SMTP Server id <ExchangeServerVersion><datetime>

The Pickup directory modifies the following message header fields if they're missing or malformed:

Message-Id If the Message-Id field is missing or empty, the Pickup directory adds a Message-Id field by using the format <GUID>@<defaultdomain>. Date If the Date field is missing or malformed, the Pickup directory adds the date and time of message processing by the Pickup directory.

Failures in Pickup Directory Message Processing

A message file copied to the Pickup directory may not be successfully queued for delivery. The following categories of message submission failure can occur:

Delivery failures A correctly formatted message file together with a valid sender that can't be successfully submitted for delivery by the Pickup directory generates a non-delivery report (NDR). Malformed content or Pickup directory message restriction violations could also cause the Pickup directory to generate an NDR. When an NDR is generated during Pickup directory message processing, the original message file is attached to the NDR message, and the message file is deleted from the Pickup directory. Note: A correctly formatted message submitted by the Pickup directory may later experience a delivery failure and be returned to the sender with an NDR. This kind of failure may be caused by transmission issues unrelated to the Pickup directory, such as messaging server failures or routing failures along the delivery path of the message. Badmail A message classified as badmail has serious problems that prevent the Pickup directory from submitting the message for delivery. The other condition that causes badmail is when the message is formatted correctly, but the recipients aren't valid, and an NDR message can't be sent to the sender because the sender isn't valid. Message files determined to be badmail are left in the Pickup directory and are renamed from <filename>.eml to <filename>.bad. If the <filename>.bad file

already exists, the file is renamed to <filename><datetime>.bad. If badmail exists in the Pickup directory, an event log error is generated, but the same badmail messages don't generate repeated event log errors. Note: Always compose and save message files in a different location before you copy them into the Pickup directory for delivery. The Pickup directory polls for new messages every five seconds. Therefore, if you try to compose and save the message files in the Pickup directory itself, the Pickup directory may try to process the message files before you finish composing them. Return to top

How the Replay Directory Processes Messages

A correctly formatted .eml message file copied to the Replay directory is processed for submission in the following steps:

1. The Replay directory is checked for new message files every five seconds. You can't modify this polling interval. You can adjust the rate of message file processing by using the PickupDirectoryMaxMessagesPerMinute parameter on the Set-TransportServer cmdlet. The default value is 100 messages per minute. Files that can't be opened are left in the Replay directory and are reevaluated at the next poll. 2. The file is renamed from <filename>.eml to <filename>.tmp. If the <filename>.tmp file already exists, the file is renamed as <filename><datetime>.tmp. If the file renaming fails, an event log error is generated, and the Replay process proceeds to the next file. 3. After the .tmp file is successfully converted into an e-mail message, a delete on close command is issued to the .tmp file. The .tmp file appears to remain in the Replay directory, but the file can't be opened. 4. After the message is successfully queued for delivery, a close command is issued, and the .tmp file is deleted from the Replay directory. If the deletion fails, an event log error is generated. If the Microsoft Exchange Transport service is restarted when there are .tmp files in the Replay directory, all .tmp files are renamed as .eml files and are reprocessed. This could lead to duplicate message transmission.

Requirements for Message Files in the Replay Directory

The Replay directory is used to resubmit exported Exchange messages and to receive messages from foreign gateway servers. These messages are already formatted for the Replay directory. There is little or no need for an administrator or other application to compose and submit new message files by using the Replay directory. The Pickup directory should be used to create and submit new message files. The Replay directory messages make extensive use of X-Headers. X-Headers are user-defined, unofficial message header fields that exist in the message header. XHeaders aren't specifically mentioned in RFC 2822, but the use of an undefined message header field starting with "X-" has become an accepted way to add unofficial message header fields to a message. The Exchange 2010-specific X-Headers used in the message files in the Replay directory can actually set delivery information that normally exists in the message envelope. This feature is required to preserve original message information when you use the Replay directory to process exported messages from another Exchange server. A message file copied to the Replay directory must meet the following requirements for successful delivery:

The message file must be a text file that complies with the basic SMTP message format. MIME message header fields and content are supported. The message file must have an .eml file name extension. X-Headers must occur before all regular header fields. A blank line must exist between the header fields and the message body. The X-Headers described in the following list are required by messages in the Replay directory:

X-Sender This X-Header replaces the From message header field requirement in a typical SMTP message. One X-Sender field that contains one e-mail address must exist. The Replay directory ignores the From message header field if it's present, although the recipient's e-mail client displays the value of the From message header field as the sender of the message. Other parameters usually exist in the X-Sender field, as shown in the following example.

X-Sender: <bob@fabrikam.com> BODY=7bit RET=HDRS ENVID=12345ABCD auth=<someAuth>

Note: These parameters are message envelope values that are ordinarily generated by the sending server. You may see parameters similar to this in exported message files. RET specifies whether the whole message or only the headers should be returned to the sender if the message can't be delivered. RET can have a value of HDRS or FULL. ENVID is a message envelope identifier. BODY specifies the text encoding of the message. auth specifies an authentication mechanism to the messaging server as described in RFC 2554. X-Receiver This X-Header replaces the To message header field requirement in a typical SMTP message. At least one X-Receiver field that contains one email address must exist. Multiple X-Receiver fields are allowed for multiple recipients. The Replay directory ignores the To message header fields if they're present, although the recipient's e-mail client displays the values of the To message header fields as the recipients of the message. Other optional parameters may exist in the X-Receiver fields, as shown in the following example.

X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com

Note: These parameters are message envelope values that are ordinarily generated by the sending server. You may see parameters similar to this in exported message files. These parameters are related to delivery status notification (DSN) messages as described in RFC 1891. NOTIFY can have a value of NEVER, DELAY, or FAILURE. ORcpt preserves the original recipient of the message. The X-Headers described in the following list are optional for message files in the Replay directory:

X-CreatedBy Used for header firewall functionality. If this X-Header exists, it must not be blank. If the X-CreatedBy field doesn't exist, it's added with a value of Unspecified. Typically, the value of this field is MSExchange14, but it also may contain the non-SMTP address space type set on a Send connector, such as Notes. X-EndOfInjectedXHeaders Size in bytes of all the X-Headers present. This X-Header may be used as a marker to indicate the last X-Header before the regular message header fields start. X-ExtendedMessageProps Extended message properties for the message. X-HeloDomain HELO/EHLO domain string presented during the initial SMTP protocol conversation. X-LegacyExch50 Used to preserve custom properties generated by Exchange Server 2003 if Exchange 2003 servers are present. X-Source Used by Queue Viewer under the MessageSourceName column. If the value of this X-Header isn't specified, the value of Replay is used. Other possible values for this X-Header are Smtp Receive Connector and Smtp Send Connector. X-SourceIPAddress IP address of the sending server. This field is 0.0.0.0 if no IP address is specified. This example shows a plain text message that uses acceptable formatting for the Replay directory.

X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com X-Sender: <bob@fabrikam.com> BODY=7bit ENVID=12345AB auth=<someAuth> Subject: Optional message subject This is the body of the message.

MIME content is also supported in Replay directory message files. MIME defines a broad range of message content that includes languages that can't be represented in 7-bit ASCII text, HTML, and other multimedia content. A complete description of MIME and its requirements is beyond the scope of this topic. This example shows a simple MIME message that uses acceptable formatting for the Replay directory.

X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com X-Sender: <bob@fabrikam.com> BODY=7bit ENVID=12345ABCD auth=<someAuth> To: mary@contoso.com From: bob@fabrikam.com Subject: Optional message subject MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit <HTML><BODY> <TABLE> <TR><TD>cell 1</TD><TD>cell 2</TD></TR> <TR><TD>cell 3</TD><TD>cell 4</TD></TR> </TABLE> </BODY></HTML>

Modifications to the Message Header That Are Made to Message Files in the Replay Directory
The Replay directory deletes the Bcc message header field from the message file. The Replay directory adds its own Received message header field to a message as part of the message submission process. The Received message header field is applied in the following format.

Received: from <ReceivingServerName> by Replay with <ExchangeServerVersion><DateTime>

The Replay directory modifies the following message header fields in the message header:

Message-ID If this message header field is missing or empty, the Replay directory adds a Message-ID message header field by using the format <GUID>@<defaultdomain>. Date If this message header field is missing or malformed, the Replay directory adds the Date message header field using the date and time of message processing by the Replay directory.

Failures in Replay Directory Message Processing

Any problems converting a message file into an e-mail message causes the Replay directory to consider the message undeliverable (badmail). A badmail message file has serious problems, such as a missing sender, missing recipients, or formatting problems. Message files determined to be badmail are left in the Replay directory and are renamed from <filename>.eml to <filename>.bad. If the <filename>.bad file already exists, the file is renamed to <filename><datetime>.bad. If badmail exists in the Replay directory, an event log error is generated, but the same badmail messages don't generate repeated event log errors. Return to top

Security Considerations for the Pickup and Replay Directories

The following list describes security concerns that are common to the Pickup directory and the Replay directory:

Any security checks configured on a Receive connector, such as anti-spam, antivirus, sender filtering, or recipient filtering actions, aren't performed on messages submitted through the Pickup directory or the Replay directory. A compromised Pickup directory or Replay directory can act as an open relay. This enables messages to be resubmitted or relayed by using a different server to mask the true source of the messages. The following list describes additional security concerns that apply to the Replay directory:

The X-Headers used by the Replay directory allow for the manual creation of the message envelope. The information in the X-Sender and X-Receiver fields can be completely different from the To or From message header fields displayed by e-mail clients. Such an impersonation of a sender and a domain is frequently called spoofing. A spoofed mail is an e-mail message that has a sending address that was modified to appear as if it originates from a sender other than the actual sender of the message. If the X-CreatedBy field has the value of MSExchange14, the destination is considered trustworthy, and a header firewall isn't applied. A header firewall is a way for Exchange to preserve X-Headers in messages transmitted between trusted Exchange 2010 servers or to remove potentially revealing X-Headers from messages transmitted to untrusted destinations outside the Exchange organization. These X-Headers can be used to share Exchange 2010 information such as spam confidence level (SCL), message signing, or encryption between authorized Exchange 2010 servers. Revealing this information to unauthorized sources could pose a potential security risk. Tighter security should be applied to the Replay directory because of the additional security risks associated with the Replay directory. Users or applications that must generate and submit messages can be granted access to the Pickup directory, but they shouldn't require access to the Replay directory. Both the Pickup directory and the Replay directory are enabled by default on all Hub Transport servers and Edge Transport servers. If the Pickup directory or the Replay directory isn't required on a specific Hub Transport server or Edge Transport server in your organization, you can disable the Pickup directory or the Replay directory on that server. For more information, see the following topics:

Configure the Pickup Directory Configure the Replay Directory Return to top

Permissions for the Pickup and Replay Directories

The following permissions are required on the Pickup and Replay directories:

Administrator: Full Control System: Full Control Network Service: Read, Write, and Delete Subfolders and Files By default, the Microsoft Exchange Transport service uses the security credentials of the Network Service user account to manage the location and permissions of the Pickup and Replay directories. The Network Service account requires these permissions on the Pickup directory so that .eml files can be opened, renamed to .tmp and deleted, or renamed to .bad if the message is classified as badmail. You can move the location of these directories by using the PickupDirectoryPath and ReplayDirectoryPath parameters on the Set-TransportServer cmdlet. Successfully changing the location of the Pickup directory depends on the rights granted to the Network Service account at the new directory locations, and whether the new directories already exist. If the directory doesn't exist, and the Network Service account has the rights required to create folders and apply permissions at the new location, the directory is created, and the correct permissions are applied to it. If the new directory already exists, the existing folder permissions aren't checked. Whenever you move the directory locations by using the PickupDirectoryPath or ReplayDirectoryPath parameter with the Set-TransportServer cmdlet, always verify that the new directory exists and that the new directory has the correct permissions applied to it. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Priority Queuing

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-02-25 Priority queuing is a feature of Microsoft Exchange Server 2010 that enables the sender-defined priority of a message to influence the processing of the message by a server running Exchange that has the Hub Transport server role installed. The message priority is assigned by the sender in Microsoft Outlook when the sender creates and sends the message. The sender can set any of the following message priority values in Outlook:

Low importance Normal importance High importance The default priority for a message created in Outlook or Microsoft Office Outlook Web App is Normal priority. The message priority is stored in the X-Priority header field in the message header. Every message sent or received in an Exchange 2010 organization must be categorized on a Hub Transport server before it can be routed and delivered. The categorizer on a Hub Transport server picks up one message at a time from the Submission queue and performs recipient resolution, routing resolution, and content conversion on the message before putting the message in a delivery queue. For more information, see Understanding Transport Pipeline. Delivery queues are dynamically created based on the destination of a message. Mailbox delivery queues are created for messages destined for Mailbox servers that exist in the same Active Directory site as the Hub Transport server. Remote delivery queues are created for messages destined for Mailbox servers that exist in a different Active Directory site than the Hub Transport server, and for remote domains. For more information, see Understanding Transport Queues. All messages that have the same destination are put in the same delivery queue. Priority queuing affects the transmission of messages from a delivery queue to the destination messaging server. When priority queuing is enabled, High priority messages are transmitted to their destinations before Normal priority messages, and Normal priority messages are transmitted to their destinations before Low priority messages. The prioritized delivery of messages based on the message priority can help you define specific service level agreement (SLA) requirements for message delivery times.

Options for Configuring Priority Queuing

All configuration options for priority queuing are available in the EdgeTransport.exe.config application configuration file located in the C:\Program Files\Microsoft\Exchange Server\V14\Bin directory. For more information about the EdgeTransport.exe.config file, see Understanding the EdgeTransport.exe.Config File. Many configuration options available are unrelated to priority queuing. Any configuration options that don't involve back pressure are outside the scope of this topic.

Enabling or Disabling Priority Queuing

The PriorityQueuingEnable parameter enables or disables priority queuing on a Hub Transport server. The default value is False. To enable priority queuing, set the PriorityQueuingEnable parameter value to True in the EdgeTransport.exe.config file and restart the Microsoft Exchange Transport service.

Configuring the Maximum Size of a High Priority Message

The MaxHighPriorityMessageSize parameter controls the maximum allowed size of a High priority message. The default value is 250 kilobytes (KB). If a High priority message is larger than the value of the MaxHighPriorityMessageSize parameter, the message is automatically downgraded from High priority to Normal priority. When you enter a value, qualify the value with one of the following units:

KB (kilobytes) MB (megabytes) GB (gigabytes) The value of the MaxHighPriorityMessageSize parameter should be significantly less than the value of the MaxMessageSize parameter on the Set-TransportConfig cmdlet. The default value of the MaxMessageSize parameter is 10 MB. A smaller value in the MaxHighPriorityMessageSize parameter helps ensure consistent and predictable delivery times for High priority messages.

Configuring the Delay Notification Time-Out Based on the Message Priority

After each message delivery failure, the Hub Transport server generates a delay delivery status notification (DSN) message and queues it for delivery to the sender of the undeliverable message. This delay DSN message is sent only after a specified delay notification time-out interval, and only if the failed message wasn't successfully delivered during that time. This delay prevents the sending of unnecessary delay DSN messages that may be caused by temporary message transmission failures. The following table shows the delay DSN notification time-out options based on the message priority.

Delay DSN notification time-out options based on the message priority

Parameter name LowPriorityDelayNotificationTimeout Default value 8:00:00 (8 hours)

NormalPriorityDelayNotificationTimeout HighPriorityDelayNotificationTimeout

4:00:00 (4 hours) 00:30:00 (30 minutes)

To specify a value for a delay notification time-out, enter the value as a time span: dd.hh:mm:ss, where d = days, h = hours, m = minutes, and s = seconds. If the value is less than 1 day, you can omit the day part of the time span.

Configuring the Message Expiration Time-Out Based on the Message Priority

The message expiration time-out specifies the maximum length of time that a Hub Transport server tries to deliver a failed message. If the message can't be successfully delivered before the expiration time-out interval has passed, a non-delivery report (NDR) that contains the original message or the message headers is delivered to the sender. The following table shows the message expiration time-out options based on the message priority.

Message expiration time-out options based on the message priority

Parameter name LowPriorityMessageExpirationTimeout NormalPriorityMessageExpirationTimeout HighPriorityMessageExpirationTimeout Default value 2.00:00:00 (2 days) 2.00:00:00 (2 days) 8:00:00 (8 hours)

To specify a value for a message expiration time-out, enter the value as a time span: dd.hh:mm:ss, where d = days, h = hours, m = minutes, and s = seconds. If the value is less than 1 day, you can omit the day part of the time span.

Configuring the Maximum Number of Connections Per Domain Based on the Message Priority
The maximum number of connections per domain specifies the maximum number of connections that a Hub Transport server can have open to any single remote domain. The outgoing connections to remote domains occur by using the remote delivery queues and Send connectors that exist on the Hub Transport server. The following table shows the maximum number of connections per domain options based on the message priority.

Maximum number of connections per domain options based on the message priority
Parameter name MaxPerDomainLowPriorityConnections MaxPerDomainNormalPriorityConnections MaxPerDomainHighPriorityConnections Default value 2 15 3

The sum of the MaxPerDomainLowPriorityConnections parameter, the MaxPerDomainNormalPriorityConnections parameter, and the MaxPerDomainNormalPriorityConnections parameter should be less than or equal to the value of the MaxPerDomainOutboundConnections parameter on the SetTransportServer cmdlet. The default value of the MaxPerDomainOutboundConnections parameter is 20.

How Priority Queuing Affects Other Message Limits on Hub Transport Servers
All messages that pass through a Hub Transport server are subject to a variety of message retry, resubmit, and expiration limits. For more information, see Understanding Transport Queues. Some message limits available in the Set-TransportServer cmdlet have corresponding priority queuing message limits available in the EdgeTransport.exe.config configuration file. The following table shows these corresponding message limits.

Message limits in the Set-TransportServer cmdlet that correspond to priority queuing message limits in the EdgeTransport.exe.config configuration file
Source Set-TransportServer EdgeTransport.exe.config Set-TransportServer EdgeTransport.exe.config Parameter DelayNotificationTimeOut NormalPriorityDelayNotificationTimeout MessageExpirationTimeOut NormalPriorityMessageExpirationTimeout Default value 4:00:00 (4 hours) 4:00:00 (4 hours) 2.00:00:00 (2 days) 2.00:00:00 (2 days)

When priority queuing is disabled, all the priority queuing message limits that exist in the EdgeTransport.exe.config configuration file are ignored. All the message limits on the Set-TransportServer cmdlet apply to all messages that travel through the Hub Transport server. When priority queuing is enabled, the priority queuing message limits in the EdgeTransport.exe.config configuration file override the corresponding message limits in

the Set-TransportServer cmdlet. All other message limits in the Set-TransportServer cmdlet still apply to Low priority, Normal priority, and High priority messages that travel through the Hub Transport server.

User Settings for Priority Queuing

The Set-Mailbox cmdlet in the Exchange Management Shell has the DowngradeHighPriorityMessagesEnabled parameter. The default value is False. When this parameter is set to True, any High priority messages sent from the mailbox are automatically downgraded to Normal priority. For more information, see SetMailbox.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Receive Connectors

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 Receive connectors are configured on computers that are running Microsoft Exchange Server 2010 and that have the Hub Transport server role or Edge Transport server role installed. Receive connectors represent a logical gateway through which all inbound messages are received. This topic provides an overview of Receive connectors and how the configuration of Receive connectors affects individual message processing.

Overview of Receive Connectors

Exchange 2010 transport servers require Receive connectors to receive messages from the Internet, from e-mail clients, and from other e-mail servers. A Receive connector controls inbound connections to the Exchange organization. By default, the Receive connectors that are required for internal mail flow are automatically created when the Hub Transport server role is installed. The Receive connector that's capable of receiving mail from the Internet and from Hub Transport servers is automatically created when the Edge Transport server role is installed. However, end-to-end mail flow is possible only after the Edge Transport server has been subscribed to the Active Directory site by using the Edge Subscription process. Other scenarios, such as an Internet-facing Hub Transport server or an unsubscribed Edge Transport server, require manual connector configuration to establish end-to-end mail flow. In Exchange 2010, the Receive connector is a receive listener. This means that the connector is listening for inbound connections that match the settings of the Receive connector. A Receive connector listens for connections that are received through a particular local IP address and port, and from a specified IP address range. You create Receive connectors when you want to control which servers receive messages from a particular IP address or IP address range, and when you want to configure special connector properties for messages that are received from a particular IP address, such as a larger message size, more recipients per message, or more inbound connections. Receive connectors are scoped to a single server and determine how that specific server listens for connections. When you create a Receive connector on a Hub Transport server, the Receive connector is stored in Active Directory as a child object of the server on which it's created. When you create a Receive connector on an Edge Transport server, the Receive connector is stored in Active Directory Lightweight Directory Services (AD LDS). If you need additional Receive connectors for specific scenarios, you can create them by using the Exchange Management Console (EMC) or the Exchange Management Shell. Each Receive connector must use a unique combination of IP address bindings, port number assignments, and the remote IP address ranges from which mail will be accepted by this connector.

Default Receive Connectors Created During Setup

Certain Receive connectors are created by default when you install a Hub Transport or Edge Transport server role.

Default Receive Connectors Created on a Hub Transport Server

When you install the Hub Transport server role, two Receive connectors are created. No additional Receive connectors are needed for typical operation, and in most cases the default Receive connectors don't require a configuration change. The usage type and configuration of these connectors are described in the following table.

Default Receive connector configuration on Hub Transport servers

Connector name and usage type Client Servername This Receive connector accepts SMTP connections from all non-MAPI clients, such as POP and IMAP. Configuration

Status: Enabled. Protocol logging level: None. Connector fully qualified domain name (FQDN): Servername.forestroot.extension Bindings: All available IP addresses. The server accepts mail received through any network adapter on the Hub Transport server. Port: 587. This is the default port for receiving messages from all non-MAPI clients for SMTP relay. Remote server IP address range: 0.0.0.0255.255.255.255 IPv4 and 0000:0000:0000:0000:0000:0000:0.0.0.0ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255 IPv6. The Hub Transport server accepts mail that's sent from any IP address. Available authentication methods: Transport Layer Security (TLS), Basic authentication, Exchange Server authentication, Integrated Windows authentication. Permission groups: Exchange users.

Default Servername This Receive connector accepts connections from other Hub Transport servers and any Edge Transport servers you have.

Status: Enabled. Protocol logging level: None. Connector FQDN: Servername.forestroot.extension Local server Receive connector bindings: All available IP addresses. The server accepts mail received through any network adapter on the Hub Transport server. Port: 25. Remote server IP address range: 0.0.0.0255.255.255.255 IPv4 and 0000:0000:0000:0000:0000:0000:0.0.0.0ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255 IPv6.. The Hub Transport server accepts mail that's sent from any IP address. Available authentication methods: TLS, Basic authentication, Integrated Windows authentication. Permission groups: Exchange users, Exchange servers, Legacy Exchange servers.

Note: Any Receive connector that's responsible for accepting connections from Edge Transport servers or other Hub Transport servers must have the Exchange Server authentication method assigned to it. The Exchange Server authentication method is the default authentication method when you create a Receive connector that has the Internal usage type.

Default Receive Connector Created on an Edge Transport Server

During installation, one Receive connector is created. This Receive connector is configured to accept SMTP communications from all IP address ranges and is bound to all IP addresses of the local server. It's configured to have the Internet usage type, and therefore, the connector accepts anonymous connections. In a typical installation, no additional Receive connectors are required. If you use EdgeSync, you don't need to make any configuration changes because the Edge Subscription process automatically configures permissions and authentication mechanisms. Anonymous sessions and authenticated sessions are granted different permission sets. If you don't use EdgeSync, we recommend that you modify the settings of this Receive connector and create an additional Receive connector of the Internal usage type. To complete Receive connector configuration, follow these steps:

1. Modify the settings of the default Receive connector Set the local network bindings to the IP address of only the Internet-facing network adapter. 2. Create a Receive connector Select Internal as the connector usage type. Set the local network bindings to the IP address of only the organization-facing network adapter. Configure the remote network settings to receive mail from the remote IP addresses that are assigned to the Hub Transport servers. Note: Any Receive connector that's responsible for accepting connections from Edge Transport servers or other Hub Transport servers must have the Exchange Server authentication method assigned to it. The Exchange Server authentication method is the default authentication method when you create a Receive connector that has the Internal usage type. 3. Determine whether Basic authentication is desired If you want to support Basic authentication, create a local user account and grant the necessary permissions by using the Add-ADPermission cmdlet. For more information, see Configure Mail Flow Between an Edge Transport Server and Hub Transport Servers Without Using EdgeSync.

Receive Connector Usage Types

The usage type determines the default security settings for the connector. The security settings for a Receive connector specify the permissions that are granted to sessions that connect to the Receive connector and the supported authentication mechanisms. When you use the EMC to configure a Receive connector, the New SMTP Receive Connector wizard prompts you to select the usage type for the connector. You can use two different methods to specify the usage type:

Use the Usage parameter with the desired value, such as Usage Custom. There are other required parameters based on the usage type that you specify. If you don't specify the required parameters in the New-ReceiveConnector command, the command will fail. Use the switch parameter for the desired usage type, such as Custom. There are other required parameters based on the usage type that you specify. If you don't specify the required parameters in the New-ReceiveConnector command, you're prompted for the missing parameter values so the command can continue.

Permission Groups
A permission group is a predefined set of permissions that's granted to well-known security principals and assigned to a Receive connector. Security principals include users, computers, and security groups. A security principal is identified by a security identifier (SID). Permission groups are only available for Receive connectors. The use of permission groups simplifies the configuration of permissions on Receive connectors. The PermissionGroups property defines the groups or roles that can submit messages to the Receive connector and the permissions that are assigned to those groups. The set of permission groups is predefined in Exchange 2010. This means that you can't create additional permission groups. Also, you can't modify the permission group members or the associated permissions. The following table lists the available permission groups and identifies the security principals and the permissions that are granted when that permission group is configured for a Receive connector. Receive connector permission groups

Permission group name Anonymous

Associated security principals (SIDs) Anonymous user account

Permissions granted

Ms-Exch-SMTP-Submit Ms-Exch-SMTP-Accept-Any-Sender Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender Ms-Exch-Accept-Headers-Routing

ExchangeUsers

Authenticated user accounts

Ms-Exch-SMTP-Submit Ms-Exch-SMTP-Accept-Any-Recipient Ms-Exch-Bypass-Anti-Spam Ms-Exch-Accept-Headers-Routing

ExchangeServers

Hub Transport servers Edge Transport servers Exchange Servers (Hub Transport server only)

Ms-Exch-SMTP-Submit Ms-Exch-SMTP-Accept-Any-Sender Ms-Exch-SMTP-Accept-Any-Recipient

Externally Secured servers

Ms-Exch-Accept-Authoritative-Domain-Sender Ms-Exch-Bypass-Anti-Spam Ms-Exch-SMTP-Accept-Authentication-Flag Ms-Exch-Bypass-Message-Size-Limit Ms-Exch-Accept-Headers-Routing Ms-Exch-Accept-Exch50 Ms-Exch-Accept-Headers-Organization Note: This permission isn't granted to Externally Secured servers. Ms-Exch-Accept-Headers-Forest Note: This permission isn't granted to Externally Secured servers.

ExchangeLegacyServers

Exchange Legacy Interop security group

Ms-Exch-SMTP-Submit Ms-Exch-SMTP-Accept-Any-Sender Ms-Exch-SMTP-Accept-Any-Recipient Ms-Exch-Accept-Authoritative-Domain-Sender Ms-Exch-Bypass-Anti-Spam Ms-Exch-SMTP-Accept-Authentication-Flag Ms-Exch-Bypass-Message-Size-Limit Ms-Exch-Accept-Headers-Routing Ms-Exch-Accept-Exch50

Partner

Partner Server account

Ms-Exch-SMTP-Submit Ms-Exch-Accept-Headers-Routing

Receive Connector Usage Types

The usage type determines the default permission groups that are assigned to the Receive connector and the default authentication mechanisms that are available for session authentication. A Receive connector always responds to a request from a sender to use TLS. The following table describes the available usage types and default settings. Receive connector usage types

Usage type Client (unavailable on Edge Transport servers)

Default permission groups ExchangeUsers

Default authentication mechanism TLS Basic authentication plus TLS Integrated Windows authentication None Exchange Server authentication

Custom Internal

None ExchangeServers ExchangeLegacyServers (This permission group is unavailable on Edge Transport servers.) AnonymousUsers Partner Partner

Internet

None or Externally Secured

Partner

Not applicable. This usage type is selected when you establish mutual TLS with a remote domain.

The Receive connector permissions and authentication mechanisms are discussed later in this topic.

Receive Connector Usage Scenarios

Each usage type is appropriate for a specific connection scenario. Select the usage type that has the default settings most applicable to the configuration that you want. You can modify permissions by using the Add-ADPermission and Remove-ADPermission cmdlets. For more information, see the following topics:

Add-ADPermission Remove-ADPermission The following table lists common connection scenarios and the usage type for each scenario. Receive Connector usage scenarios

Connector scenario

Usage type

Comment

Edge Transport server receiving e-mail from the Internet Hub Transport server receiving e-mail from the Internet Edge Transport server receiving e-mail from an Exchange Server 2003 bridgehead server Hub Transport server receiving e-mail submissions from a client application that uses POP3 or IMAP4 Hub Transport server receiving e-mail from a Hub Transport server Hub Transport server receiving e-mail from an Exchange 2003 bridgehead server in the same forest

Internet

A Receive connector that's configured to accept e-mail from all domains is created automatically when the Edge Transport server role is installed. This isn't a recommended configuration. For more information, see Configure Internet Mail Flow Directly Through a Hub Transport Server. In this scenario, the Exchange 2003 bridgehead server is configured to use the Edge Transport server as a smart host for a Send connector.

Internet

Internal

Client

This Receive connector is automatically created on every Hub Transport server when the role is installed. By default, this Receive connector is configured to receive e-mail through TCP port 587.

Internal

You don't have to configure Receive connectors between Hub Transport servers within the same organization. This usage type can be used to configure a cross-forest Receive connector. This is an optional configuration. Transport between Exchange 2010 and earlier versions of Exchange is accomplished through two-way routing group connectors. If you create SMTP connectors to Exchange 2003 routing groups, a routing group connector must also exist. For more information, see Create Additional Routing Group Connectors from Exchange 2010 to Exchange 2003. A Receive connector that's configured to accept e-mail from all domains is created automatically when the Edge Transport server role is installed. You can create another connector and configure it to receive e-mail only from the Exchange organization. For detailed configuration steps, see Configure Cross-Forest Connectors.

Internal

Edge Transport server receiving e-mail from a Hub Transport server

Internal

Cross-forest Receive connector for a Hub Transport server in one forest receiving e-mail from a Hub Transport server in a second forest Cross-forest Receive connector for a Hub Transport server in one forest receiving e-mail from an Exchange 2003 bridgehead server in a second forest Hub Transport server receiving e-mail from a third-party message transfer agent (MTA) Edge Transport server receiving e-mail from a third-party MTA

Custom

Custom

For detailed configuration steps, see Configure Cross-Forest Connectors.

Internal

Specify the IP address range from which messages will be accepted and set the authentication mechanism to either Basic authentication or Externally Secured.

Custom

Use the Add-ADPermission cmdlet to set the extended rights. Specify the IP address range from which messages will be accepted and set the authentication mechanism to Basic authentication. You can also select the Internal usage type and set Externally Secured as the authentication method. No additional permissions configuration is required if you select this option. The Edge Transport server can accept e-mail from an external relay domain and then relay to the destination recipient domain. Specify the IP address range from which messages will be accepted, set the appropriate authentication mechanism, and use the Add-ADPermission cmdlet to set the extended rights. Mutual TLS authentication functions correctly only if the following conditions are true: The value of the DomainSecureEnabled parameter is set to $true. The value of the AuthMechanism parameter contains TLS and doesn't contain External. The TLSReceiveDomainSecureList parameter in the Transport configuration contains at least one domain that's serviced by this Receive connector. The wildcard character (*) isn't supported in domains that are configured for mutual TLS authentication. The same domain must also be defined on the corresponding Send connector, and in the value of the TLSSendDomainSecureList parameter in the Transport configuration. For more information, see Set-ReceiveConnector.

Edge Transport server receiving e-mail from an external relay domain

Custom

Edge Transport server receiving e-mail from a domain to which you have established mutual TLS authentication

Partner

Edge Transport server receiving connections from Microsoft Exchange Hosted Services server Hub Transport server receiving connections from an Exchange Hosted Services server

Custom

The Exchange Hosted Services server can act as an externally authoritative server. To use the Externally Secured authentication mechanism, use the Set-ReceiveConnector cmdlet to set the PermissionGroup parameter to ExchangeServers. The Exchange Hosted Services server can act as an externally authoritative server. To use the Externally Secured authentication mechanism, use the Set-ReceiveConnector cmdlet to set the PermissionGroup parameter to ExchangeServers.

Custom

Receive Connector Permissions

Receive connector permissions are assigned to security principals when you specify the permission groups for the connector. When a security principal establishes a session with a Receive connector, the Receive connector permissions determine whether the session is accepted and how the received messages are processed. The following table describes the permissions that can be assigned on a Receive connector to security principals. You can set Receive connector permissions by using the EMC or by using the PermissionGroups parameter with the Set-ReceiveConnector cmdlet in the Shell. To modify the default permissions for a Receive connector, you can also use the Add-ADPermission cmdlet.

Receive connector permissions

Receive connector permission ms-Exch-SMTPSubmit ms-Exch-SMTPAccept-AnyRecipient ms-Exch-SMTPAccept-Any-Sender ms-Exch-SMTPAcceptAuthoritativeDomain-Sender ms-Exch-SMTPAcceptAuthentication-Flag ms-Exch-AcceptHeaders-Routing ms-Exch-AcceptHeadersOrganization ms-Exch-AcceptHeaders-Forest ms-Exch-AcceptExch50 ms-Exch-BypassMessage-SizeLimit Ms-Exch-BypassAnti-Spam

Description

The session must be granted this permission or it will be unable to submit messages to this Receive connector. If a session doesn't have this permission, the MAIL FROM and AUTH commands will fail. This permission allows the session to relay messages through this connector. If this permission isn't granted, only messages that are addressed to recipients in accepted domains are accepted by this connector.

This permission allows the session to bypass the sender address spoofing check.

This permission allows senders that have e-mail addresses in authoritative domains to establish a session to this Receive connector.

This permission allows Exchange 2003 servers to submit messages from internal senders. Exchange 2010 will recognize the messages as being internal. The sender can declare the message as trusted. Messages that enter your Exchange system through anonymous submissions will be relayed through your Exchange organization with this flag in an untrusted state. This permission allows the session to submit a message that has all received headers intact. If this permission isn't granted, the server will strip all received headers. This permission allows the session to submit a message that has all organization headers intact. Organization headers all start with X-MSExchange-Organization-. If this permission isn't granted, the receiving server will strip all organization headers.

This permission allows the session to submit a message that has all forest headers intact. Forest headers all start with X-MS-Exchange-Forest-. If this permission isn't granted, the receiving server will strip all forest headers. This permission allows the session to submit a message that contains the XEXCH50 command. This command is needed for interoperability with Exchange 2003. The XEXCH50 command provides data such as the spam confidence level (SCL) for the message. This permission allows the session to submit a message that exceeds the message size restriction configured for the connector.

This permission allows the session to bypass anti-spam filtering.

Local Network Settings

In the EMC, you use the local network settings for a Receive connector to specify the IP address and port through which the transport server accepts connections. In the Shell, use the Bindings parameter to specify the local IP address and port of the transport server through which the Receive connector accepts connections. These settings bind the Receive connector to a particular network adapter and TCP port on the transport server. By default, a Receive connector is configured to use all available network adapters and TCP port 25. If a transport server has multiple network adapters, you may want a Receive connector to be bound to a particular network adapter, or to accept connections through an alternative port. For example, you may want to configure one Receive connector on the Edge Transport server to accept anonymous connections through the external network adapter. A second Receive connector can be configured to accept connections from only Hub Transport servers through the internal network adapter. Note: If you choose to bind a Receive connector to a specific local IP address, that IP address must be valid for the Hub Transport server or Edge Transport server on which the Receive connector is located. If you specify an invalid local IP address, the Microsoft Exchange Transport service may fail to start when the service is restarted. Instead of binding the Receive connector to a specific IP address, you can bind the Receive connector to all available IP addresses on the Hub Transport server or Edge Transport server. Specify the IP address of the network adapter when you configure Receive connector bindings. If the Receive connector is configured to accept connections through a port other than the default, the sending client or server must be configured to send to that port and any firewalls between the message sender and the receiving server must allow network traffic through that port. The Local Network Settings page of the New SMTP Receive Connector wizard in the EMC includes an option to Specify the FQDN this connector will provide in response to HELO or EHLO. In the Shell, this property is set by using the Fqdn parameter with the Set-ReceiveConnector cmdlet. After an SMTP session is established, an SMTP protocol conversation starts between a sending e-mail server and a receiving e-mail server. The sending e-mail server or client sends the EHLO or HELO SMTP command and its FQDN to the receiving server. In response, the receiving server sends a success code and provides its own FQDN. In Exchange 2010, you can customize the FQDN that's provided by the receiving server if you configure this property on a Receive connector. The FQDN value is displayed to connected messaging servers whenever a destination server name is required, as in the following examples:

In the default SMTP banner of the Receive connector In the most recent Received: header field in the incoming message when the message enters the Hub Transport server or Edge Transport server During TLS authentication

Note: Dont modify the FQDN value on the default Receive connector named Default <Server Name> that's automatically created on Hub Transport servers. If you have multiple Hub Transport servers in your Exchange organization and you change the FQDN value on the Default <Server Name> Receive connector, internal mail flow between Hub Transport servers will fail.

Remote Network Settings

In the EMC, you use the remote network settings for a Receive connector to specify the IP address ranges from which this Receive connector accepts connections. In the Shell, you use the RemoteIPRanges parameter to specify the IP address ranges from which this Receive connector accepts connections. By default, Receive connectors are created on Hub Transport servers and Edge Transport servers that allow connections from 0.0.0.0255.255.255.255, or from every IP address. Note: In Exchange 2010 , the IPv6 address range 0000:0000:0000:0000:0000:0000:0.0.0.0ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255 also exists in the default Receive connectors on a Hub Transport server. If you're configuring a Receive connector for a specific scenario, set the remote network settings to only the IP addresses of the servers that should be allowed the permissions and configuration settings for the Receive connector. Multiple Receive connectors can have overlapping remote IP address ranges as long as one range is completely overlapped by another. When remote IP address ranges overlap, the remote IP address range that has the most specific match to the connecting server's IP address is used. The IP address or IP address range for the remote servers from which the Receive connector will accept inbound connections is entered in one of the following formats:

IP address 192.168.1.1 IP address range 192.168.1.10-192.168.1.20 IP address together with subnet mask 192.168.1.0(255.255.255.0) IP address together with subnet mask by using Classless Interdomain Routing (CIDR) notation 192.168.1.0/24

Receive Connector Authentication Settings

In the EMC, you use the authentication settings for a Receive connector to specify the authentication mechanisms that are supported by the Exchange 2010 transport server. In the Shell, you use the AuthMechanisms parameter to specify the supported authentication mechanisms. You can configure more than one authentication mechanism for a Receive connector. For the authentication mechanisms that are automatically configured for each usage type, see the table labeled "Receive connector usage types" earlier in this topic. The following table lists the available authentication mechanisms for a Receive connector. Receive connector authentication mechanisms

Authentication mechanism None TLS Integrated BasicAuth BasicAuthRequireTLS ExchangeServer ExternalAuthoritative

Description

No authentication. Advertise STARTTLS. Requires availability of a server certificate to offer TLS. NTLM and Kerberos (Integrated Windows authentication). Basic authentication. Requires an authenticated logon. Basic authentication over TLS. Requires a server certificate. Exchange Server authentication (Generic Security Services application programming interface (GSSAPI) and Mutual GSSAPI). The connection is considered externally secured by using a security mechanism that's external to Exchange. The connection may be an Internet Protocol security (IPsec) association or a virtual private network (VPN). Alternatively, the servers may reside in a trusted physically controlled network. The ExternalAuthoritative authentication method requires the ExchangeServers permission group. This combination of authentication method and security group permits the resolution of anonymous sender e-mail addresses for messages that are received through this connector. This replaces the Resolve anonymous senders function in Exchange Server 2003.

Additional Receive Connector Properties

The property configuration for a Receive connector defines how e-mail is received through that connector. Not all properties are available in the EMC. For more information about the properties that can be configured by using the Shell, see Set-ReceiveConnector.

Using a Receive Connector for Anonymous Relay

Anonymous relay on Internet SMTP messaging servers is a serious security deficiency that could be exploited by unsolicited commercial e-mail senders, or spammers, to hide the source of their messages. Therefore, restrictions are placed on Internet-facing messaging servers to prevent relaying to unauthorized destinations. In Exchange 2010, relaying is typically handled by using accepted domains. Accepted domains are configured on the Edge Transport server or Hub Transport server. The accepted domains are additionally classified as internal relay domains or external relay domains. For more information about accepted domains, see Understanding Accepted Domains.

You can also restrict anonymous relay based on the source of the incoming messages. This method is useful when an unauthenticated application or messaging server must use a Hub Transport server or an Edge Transport server as a relay server. When you create the Receive connector that's configured to allow anonymous relay, you should place the following restrictions on the Receive connector:

Local network settings Restrict the Receive connector to listen only on the appropriate network adapter on the Hub Transport server or Edge Transport server. Remote network settings Restrict the Receive connector to accept connections only from the specified server or servers. This restriction is necessary, because the Receive connector is configured to accept relay from anonymous users. Restricting the source servers by IP address is the only measure of protection that's allowed on this Receive connector. To grant the relay permission to anonymous users on the Receive connector, you can use either of the strategies described later in this topic. Each strategy has advantages and disadvantages. For step by step instructions for both approaches, see Allow Anonymous Relay on a Receive Connector.

Granting Relay Permission to Anonymous Connections

This strategy involves the following tasks:

Creating a Receive connector with the usage type set to Custom. Adding the Anonymous permission group to the Receive connector. Assigning the relay permission to the Anonymous Logon security principal on the Receive connector. The Anonymous permission group grants the following permissions to the Anonymous Logon security principal on the Receive connector:

Ms-Exch-Accept-Headers-Routing Ms-Exch-SMTP-Accept-Any-Sender Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender Ms-Exch-SMTP-Submit However, to allow anonymous relay on this Receive connector, you must also grant the following permission to the Anonymous Logon security principal on the Receive connector:

Ms-Exch-SMTP-Accept-Any-Recipient The advantage of this strategy is that it grants the minimum required permissions to relay to the specified remote IP addresses. The disadvantages of this strategy are as follows:

Additional configuration steps are required to grant the necessary permissions. The messages that originate from the specified IP addresses are treated as anonymous messages. Therefore, the messages don't bypass anti-spam checks, don't bypass message size limit checks, and anonymous senders can't be resolved. The process of resolving anonymous senders forces an attempted match between the anonymous sender's e-mail address and the corresponding display name in the global address list (GAL).

Configuring the Receive Connector as Externally Secured

This strategy involves the following tasks:

Creating a Receive connector with the usage type set to Custom. Adding the ExchangeServers permission group to the Receive connector. Adding the ExternalAuthoritative authentication mechanism to the Receive connector. The ExchangeServers permission group is required when you select the ExternalAuthoritative authentication mechanism. This combination of authentication method and permission group grants the following permissions to any incoming connection that's permitted on the Receive connector:

Ms-Exch-Accept-Headers-Routing Ms-Exch-SMTP-Accept-Any-Sender Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender Ms-Exch-SMTP-Submit Ms-Exch-Accept-Exch50 Ms-Exch-Bypass-Anti-Spam Ms-Exch-Bypass-Message-Size-Limit Ms-Exch-SMTP-Accept-Any-Recipient Ms-Exch-SMTP-Accept-Authentication-Flag The advantages of this strategy are as follows:

Ease of configuration The messages that originate from the specified IP addresses are treated as authenticated messages. The messages bypass anti-spam checks, bypass message size limit checks, and can resolve anonymous senders. The disadvantage of this strategy is that the remote IP addresses are considered completely trustworthy. The permissions that are granted to the remote IP addresses allow the remote messaging server to submit messages as if they originated from internal senders within your Exchange organization.

New Features in Exchange 2010 Service Pack 1

In Service Pack 1 (SP1) for Exchange Server 2010, new functionality was added to Receive connectors. This section provides an overview of these new features.

Bare Line Feed Control

When a mail server establishes an SMTP session, it issues SMTP commands to send messages. After specifying the sender and recipient information, the sending server transmits the contents of the message using the DATA command. The content that is transmitted after issuing the DATA command is known as the data stream. The data stream is terminated by a special sequence of characters: a carriage return line feed (CRLF), followed by a period, followed by another CRLF. Line feed LF characters that arent immediately preceded by carriage return CR characters are known as bare line feeds. Bare line feeds arent allowed in SMTP communications. Although it may be possible for a message containing a bare line feed to be delivered successfully, such messages don't adhere to the SMTP protocol standards and may cause problems with messaging servers. In Exchange 2010 SP1, you can configure your Receive connectors to reject any messages that contain bare line feeds in their data stream. This behavior is controlled by the BareLineFeedRejectionEnabled parameter of the Set-ReceiveConnector cmdlet. By default, this setting is disabled to maintain backwards compatibility. For more information about configuring this parameter, see Set-ReceiveConnector.

Extended Protection Capability

Windows offers channel binding to protect NTLM authentication over encrypted channels from authentication relay attacks. In Exchange 2010, all services provided by Exchange have been updated to support Extended Protection for Authentication. To support this feature in Transport, the Receive connectors have been updated. You can allow, require, or disable Extended Protection for Authentication on your Receive connectors. You can use the ExtendedProtectionPolicy and ExtendedProtectionTlsTerminatedAtProxy parameters of the Set-ReceiveConnector cmdlet to control how your Transport servers handle extended protection. You can configure a Receive connector to allow or require extended protection. When you configure a Receive connector to require extended protection, any incoming connections from hosts that don't support extended protection will be rejected. To maintain backwards compatibility, the extended protection is disabled by default. For more information about configuring extended protection on your Receive connectors, see Set-ReceiveConnector. To learn more about extended protection, see the following resources:

Microsoft Knowledge Base article 973811, Microsoft Security Advisory: Extended protection for authentication MSDN Library topic, Integrated Windows Authentication with Extended Protection

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Recipient Resolution

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-01-25 Recipient resolution is the process of expanding and resolving all the recipients in a message. The act of resolving the recipients matches a recipient to the corresponding Active Directory object in the Microsoft Exchange organization. The act of expanding the recipients expands all distribution groups into a list of individual recipients. Recipient resolution allows message limits and alternative recipients to be applied correctly to each recipient. In a Microsoft Exchange Server 2010 organization, recipient resolution is performed by the categorizer on a server that has the Hub Transport server role installed. Categorization on each message happens after a newly arrived message is put in the Submission queue. Recipient resolution, in addition to content conversion and routing, is performed on the message before the message is put in a delivery queue. The categorizer performs recipient resolution before routing. The component of the categorizer that's responsible for recipient resolution is frequently called the resolver. Contents Top-Level Resolution Expansion Bifurcation and Controlling Recipient Expansion Recipient Resolution Diagnostics

Top-Level Resolution

Top-level resolution is the first stage of recipient resolution. Top-level resolution associates each recipient in an incoming message to a matching recipient object in Active Directory. During top-level resolution, the categorizer creates a list that contains the sender and the initial, unexpanded recipient e-mail addresses that exist within the message. The categorizer then uses that list of e-mail addresses to query Active Directory to find any mail-enabled objects that have matching e-mail address attributes. When a match is found, the properties of matching Active Directory objects are cached for later use. Any sender message restrictions are also enforced.

Recipient E-mail Addresses

Top-level resolution begins with a message and the initial, unexpanded list of recipients from the message envelope. The message envelope contains the commands that are used to transmit messages among SMTP messaging servers. The sender's e-mail address is contained in the MAIL FROM: command. Each recipient's e-mail address is contained in a separate RCPT TO: command. The envelope sender and envelope recipients are typically created from the sender and recipients in the To:, From:, Cc:, and Bcc: header fields in the message header. However, this isn't always true. The To:, From:, Cc:, and Bcc: header fields in a message are easily forged and may not match the actual sender or recipient e-mail addresses that were used to transmit the message.

Encapsulated E-mail Addresses

Standard SMTP e-mail addresses follow the specifications of RFC 2821 and RFC 2822, such as chris@contoso.com, for example. However, an e-mail address can also be a non-SMTP e-mail address that's encapsulated inside a valid SMTP address. Exchange 2010 supports encapsulated addresses that use the Internet Mail Connector Encapsulated Address (IMCEA) encapsulation method. This encapsulation method requires the encoding of any characters that are invalid in SMTP e-mail addresses. Alphanumeric characters, the equal sign (=) and the hyphen (-) don't require encoding. Other characters use the following encoding syntax:

A forward slash (/) is replaced by an underscore (_). Other US-ASCII characters are replaced by a plus sign (+) and the two digits of its ASCII value are written in hexadecimal. For example, the space character has the encoded value +20. The IMCEA encapsulation method uses the following syntax: IMCEA<Type>-<address>@<domain> The placeholder <Type> identifies the type of non-SMTP address, for example EX, X400, or FAX.

Note: Although SMTP and X500 are theoretically valid values for <Type>, Exchange 2010 recipient resolution rejects any IMCEA-encoded addresses that use either of these types. The placeholder <address> is the encoded original address. The placeholder <domain> represents the SMTP domain that's used to encapsulate the non-SMTP address, for example, contoso.com With the IMCEA encapsulation method, addresses are unencapsulated only when the domain matches the default authoritative domain in the Exchange organization. For more information about accepted domains, see Understanding Accepted Domains. The maximum length for an SMTP e-mail address in Exchange 2010 is 571 characters. This limit includes the following:

315 characters for the name part of the address 255 characters for the domain name

The at sign (@) character that separates the name part of the address from the domain name Currently, Exchange 2010 doesn't support messages that are encoded with the IMCEA encapsulation method when the name part of the address exceeds 315 characters.

Address Resolution
For each message, the sender e-mail address and all recipient e-mail addresses are added to a list that's used to query Active Directory. Any encapsulated addresses are unencapsulated before they're added to the list of e-mail addresses. The Active Directory query is performed on up to 20 e-mail addresses at a time. If the Active Directory query encounters any transient errors, the message is returned to the Submission queue and deferred for the time that's specified by the ResolverRetryInterval parameter in the EdgeTransport.exe.config application configuration file. The default value is 30 minutes. The following table describes the recipient objects that are found in Active Directory. For more information about Exchange 2010 recipient types, see Understanding Recipients.

Recipient objects in Active Directory

Active Directory recipient type DistributionGroup Description

Any mail-enabled group object. The distribution group object types are as follows: MailUniversalDistributionGroup A universal distribution group object MailUniversalSecurityGroup A universal security group (USG) object that has an e-mail address MailNonUniversalGroup A local security group object or global security group object that has an e-mail address

DynamicDistributionGroup

An object that has the Active Directory class msExchDynamicDistributionList. For more information, see Create a Dynamic Distribution Group. A user object that has an e-mail address and a defined Database parameter A user object that has an e-mail address without a defined Database parameter. For more information, see Create a Mail User. A contact object that has an e-mail address. Typically, a mail contact is used for recipients outside the Exchange organization. A mail contact is also used in cross-forest Exchange environments. For more information, see Create a Mail Contact. A public folder object that has an e-mail address. An object that has the Active Directory class msExchExchangeServerRecipient. For more information about the Exchange recipient object, see Understanding the Microsoft Exchange Recipient. An object that has the Active Directory class msExchPublicMDB. An object that has the Active Directory class exchangeAdminService. There should be only one system attendant mailbox in the Exchange 2010 organization. A user object that has an e-mail address and that's located in the Microsoft Exchange System Objects container. There should be one system mailbox for each mailbox database in the Exchange 2010 organization.

Mailbox MailUser MailContact

MailPublicFolder MicrosoftExchangeRecipient

PublicDatabase SystemAttendantMailbox

SystemMailbox

An object that contains missing or malformed critical properties is classified by the Active Directory query as an invalid object. For example, a dynamic distribution group object without an e-mail address is considered invalid. Messages that are sent to recipients that are classified as invalid objects generate a non-delivery report (NDR). For each e-mail address, a single initial query is performed for all possible recipient properties, such as the recipient identifiers, recipient type, message limits, e-mail addresses, and alternative recipients. The applicable properties for the recipient are cached for later use. Recipient resolution classifies the recipients based on similarities in how the recipients are resolved, and the similarity of the applicable recipient properties. The LDAP filter that's used for address resolution is described as follows:

For the EX e-mail address type, the LDAP filter is based on the recipient legacyExchangeDN Active Directory attribute or the recipient proxyAddresses Active Directory attribute. The legacyExchangeDN Active Directory attribute takes precedence. For all other e-mail addresses types, the recipient proxyAddresses Active Directory attribute is used as the LDAP filter. If the e-mail address that's used in the message doesn't match the primary SMTP address of the corresponding Active Directory object, the categorizer rewrites the email address in the message to match the primary SMTP address. The original e-mail address is saved in the ORCPT= parameter in the RCPT TO: command in the message envelope.

Sender Message Restrictions

The size that's used for the sender message size restriction is the value of the X-MS-Exchange-Organization-OriginalSize: header field in the message header. Exchange 2010 uses this header field to record the original message size of the message when it entered the Exchange 2010 organization. Whenever the message is checked against the specified message size limits, the lower value of the current message size or the original message size header is used. The size of the message can change because of content conversion, encoding, and agent processing. If this header field doesn't exist, it's created by using the current message size value. If the message is too large, an NDR is generated and additional message processing is stopped. The sender recipient limit is only enforced on the first Hub Transport server that processes the message. The original, unexpanded message envelope recipient count is compared to the sender recipient limit. The original, unexpanded message envelope recipient count is used to avoid the partial message delivery problems that

occur in Microsoft Exchange Server 2003 when nested distribution lists used remote expansion servers. The message sender and all recipients are marked as resolved by stamping an extended property in the message. This extended property allows the message to bypass top-level resolution if the message must go through recipient resolution again. A message may have to go through recipient resolution again because the Microsoft Exchange Transport service restarted. Return to top

Expansion
Expansion occurs after top-level resolution. Expansion completely expands nested levels of recipients into individual recipients. Expansion may require multiple trips through the expansion process to expand all recipients. Not all recipients have to be expanded. However, all recipients must go through the expansion process. The expansion process also enforces recipient message restrictions for all kinds of recipients. The following list describes the kinds of recipients that require expansion:

Distribution groups and dynamic distribution groups Distribution groups are expanded based on the memberOf Active Directory property. Dynamic distribution groups are expanded by using the Active Directory query definition. If the ExpansionServer parameter is set on the group, the group isn't expanded by the current server. The distribution group is routed to the specified server for expansion. Note: If you select a specific Hub Transport server in your organization as the expansion server, the distribution group usage becomes dependent on the availability of the expansion server. If the expansion server is unavailable, any messages that are sent to the distribution group can't be delivered. If you plan to use specific expansion servers for your distribution groups, to reduce the risk of service interruption, you should consider implementing high availability solutions for these servers. Alternative recipients The ForwardingAddress parameter may be set on mailboxes and mail-enabled public folders. The ForwardingAddress parameter redirects all messages to the specified alternative recipient. This is known as a forwarded recipient. When an alternative delivery address is specified in the ForwardingAddress parameter and the DeliverToMailboxAndForward parameter is set to $true, the message is delivered to the original recipient and the alternative recipient. This is known as delivered and forwarded recipient. Contact chains A contact chain is a mail user or mail contact that has the ExternalEmailAddress parameter set to the e-mail address of another recipient in the Exchange organization.

Detection of Recipient Loops

As the distribution groups, alternative recipients, and contacts chains are expanded, the categorizer checks for recipient loops. A recipient loop is a recipient configuration problem that causes message delivery to the same recipients in an endless circle. The following list describes the different types of recipient loops:

Harmless recipient loop A harmless recipient loop results in successful message delivery. The following list describes two scenarios when harmless recipient loops occur: When two distribution groups contain one another as members. When mailboxes or mail-enabled public folders are set to deliver and forward to one another. This happens when the DeliverToMailboxAndForward parameter of both recipients is set to $true and the ForwardingAddress parameter is set to one another. When a harmless recipient loop is detected, the message is delivered to the recipient, but no additional attempts are made to deliver the message to the same recipient. Broken recipient loop A broken recipient loop can't result in successful message delivery. An example of a broken recipient loop is when mailboxes or mailenabled public folders have the ForwardingAddress parameter set to one another. When the categorizer detects a broken recipient loop, expansion activity for the current recipient stops, and an NDR is generated for the recipient. Detection of recipient loops doesn't prevent duplicate message delivery. For example, Distribution Group C will experience duplicate message delivery if the following conditions are true:

Distribution Group B and Distribution Group C are members of Distribution Group A. Distribution Group C is also a member of Distribution Group B.

Delivery Report Redirection for Distribution Groups

When a distribution group is expanded, the message type is checked to determine whether it's a delivery report message. If the message is a delivery report, the redirection settings of the distribution group are checked to determine whether redirection of the delivery report is required. You may want to suppress the delivery reports because the delivery reports may disclose unwanted information about the distribution group and its membership. The following list describes the delivery report redirection settings that are available for distribution groups and dynamic distribution groups:

ReportToManagerEnabled This parameter enables delivery reports to be sent to the distribution group manager. Valid values are $true or $false. The default value is $false. For a distribution group, the manager is controlled by the ManagedBy parameter in the Set-Group cmdlet. For a dynamic distribution group, the manager is controlled by the ManagedBy parameter in the Set-DynamicDistributionGroup cmdlet. ReportToOriginatorEnabled This parameter enables delivery reports to be sent to the sender of e-mail messages that are sent to this distribution group. Valid values are $true or $false. The default value is $true. Note: The values of the ReportToManagerEnabled parameter and ReportToOriginatorEnabled parameter can't both be $true. If one parameter is set to $true, the other must be set to $false. The values of both parameters can be $false. This suppresses all redirection of all delivery report messages. The following list describes the available delivery report messages:

Delivery receipt (DR) This report confirms that a message was delivered to its intended recipient. Delivery status notification (DSN) This report describes the result of an attempt to deliver a message. For more information about DSN messages, see

Managing Delivery Status Notifications. Message disposition notification (MDN) This report describes the status of a message after it has been successfully delivered to a recipient. A read notification (RN) and a non-read notification (NRN) are both examples of an MDN message. MDN messages are defined in RFC 2298 and are controlled by the Disposition-Notification-To: header field in the message header. MDN settings that use the Disposition-Notification-To: header field are compatible with many different message servers. MDN settings can also be defined by using MAPI properties in Microsoft Outlook and Exchange. Non-delivery report (NDR) This report indicates to the message sender that the message couldn't be delivered to the specified recipients. Non-read notification (NRN) This report indicates that a message was deleted before it was read. Out of office (OOF) This report indicates that the recipient won't respond to e-mail messages. The acronym OOF dates back to the original Microsoft messaging system where the corresponding notification was named "out of facility." Read notification (RN) This report indicates that a message was read. Recall Report This report indicates the status of a recall request for a specific recipient. A recall request is when a sender tries to recall a sent message by using Outlook. When a delivery report message is sent to a distribution group, the following settings cause the report message to be deleted:

Report redirection isn't set. Alternatively, report redirection is set to the message sender. Report redirection is set to the distribution group manager, and the delivery report message isn't an NDR. When a delivery report message is sent to a distribution group, the following setting causes the delivery report message to be delivered to the distribution group manager:

Report redirection is set to the distribution group manager, and the report message is an NDR. When a message that isn't a delivery report message is sent to a distribution group, the message is delivered to the distribution group members. The report request settings are summarized in the following list:

If report redirection is set to the message sender, the report request settings aren't modified. If report redirection isn't set, all report request settings are suppressed. The NOTIFY=NEVER parameter is added to RCPT TO: for each recipient in the message envelope. If report redirection is set to the distribution group manager, all report request settings are suppressed except NDR messages that are sent to the distribution group manager.

Message Restrictions on Recipients

The expansion process also enforces any message restrictions that are configured for recipients. These restrictions may be configured individually for each recipient or organizationally for all Hub Transport servers in the Exchange organization. The following table describes the message restrictions that are configured for recipients.

Message restrictions on recipients

Source Set-DistributionGroup SetDynamicDistributionGroup Set-Mailbox Set-MailContact Set-MailPublicFolder Set-MailUser Set-TransportConfig Parameter MaxReceiveSize Description The MaxReceiveSize parameter specifies the size that's used for message restrictions that are configured for recipients is the value of the X-MS-Exchange-OrganizationOriginalSize: header field in the message header. Exchange 2010 uses this header field to record the original message size of the message when it entered the Exchange 2010 organization. Whenever the message is checked against the specified message size limits, the lower value of the current message size or the original message size header is used. The size of the message can change because of content conversion, encoding, and agent processing. If this header field doesn't exist, it's created by using the current message size value. If the message is too large, an NDR is generated and additional message processing is stopped. RequireSenderAuthenticationEnabled The RequireSenderAuthenticationEnabled parameter requires that all messages that are sent to the recipient come from authenticated senders. When the value of this parameter is set to $true, messages from unauthenticated senders are rejected. All senders who send messages to the System and System Attendant mailboxes must be authenticated.

Set-DistributionGroup SetDynamicDistributionGroup Set-Mailbox Set-MailContact Set-MailPublicFolder Set-MailUser Set-DistributionGroup SetDynamicDistributionGroup Set-Mailbox Set-MailContact Set-MailPublicFolder Set-MailUser

AcceptMessagesOnlyFrom AcceptMessagesOnlyFromDLMembers RejectMessagesFrom RejectMessagesFromDLMembers

The AcceptMessagesOnlyFrom parameter specifies the senders who can send e-mail messages to the recipient. The AcceptMessagesOnlyFromDLMembers parameter specifies the distribution groups that can send e-mail messages to the recipient. The RejectMessagesFrom parameter specifies the senders that can't send e-mail messages to this recipient. The RejectMessagesFromDLMembers parameter specifies the distribution groups that can't send e-mail messages to the distribution group. The categorizer checks the recipient permission in two passes. The first pass determines whether the sender is present in the AcceptOnlyMessagesFrom or RejectMessagesFrom parameter. If the sender isn't found in either parameter, the recipients in the AcceptMessagesOnlyFromDLMembers and RejectMessagesFromDLMembers parameters are fully expanded. This complete expansion of distribution groups may take some time. We recommend that you minimize the depth of nested distribution groups in the AcceptMessagesOnlyFromDLMembers parameter and the RejectMessagesFromDLMembers parameters.

Certain types of messages that are sent by authenticated senders are exempt from restrictions. The following list describes the messages that are exempt from recipient restrictions:

All messages that are sent by the Microsoft Exchange recipient These messages include DSN messages, journal reports, quota messages, and other system-generated messages that are sent to internal message senders. For more information about the Microsoft Exchange recipient, see Understanding the Microsoft Exchange Recipient. Public folder replication messages These messages are sent by a public database sender. All messages that are sent by the external postmaster address These messages include DSN messages and other system-generated messages that are sent to external message senders. For more information about the external postmaster address, see Configure the External Postmaster Address. Certain types of messages are blocked when they are sent from the Exchange organization to external domains. The settings are controlled by the following parameters in the Set-RemoteDomain cmdlet:

AllowedOOFType AutoForwardEnabled AutoReplyEnabled DeliveryReportEnabled NDREnabled For more information, see Understanding Remote Domains. Return to top

Bifurcation and Controlling Recipient Expansion

Because the complete list of message recipients is expanded and resolved by recipient resolution, there are occasions when different copies of the same message must be created. These occasions are described by the following scenarios:

When message recipients require different message settings Message properties such as read receipts may have to be enabled for some recipients and blocked for other recipients. Creating a new version of the message that has slightly different properties than the original message is called bifurcation. To limit the number of envelope recipients in a single message The recipient expansion process can generate thousands of individual recipients when large distribution groups are expanded. In Exchange 2010, instead of creating a single copy of the message that has thousands of envelope recipients, multiple copies of the same message that have a limited number of envelope recipients are created.

Bifurcation
Recipient resolution bifurcates a message if the following conditions are true:

When the message sender in MAIL FROM:, in the message envelope, is updated. An example is when the ReportToManagerEnabled parameter on a distribution group has a value of $true. When auto-response messages, such as DSNs, OOF messages, and recall reports must be suppressed. When alternative recipients are expanded. When a Resent-From: header field must be added to the message header. Resent header fields are informational header fields that can be used to determine whether a message has been forwarded by a user. Resent header fields are used so that the message appears to the recipient as if it was sent directly by the original sender. The recipient can view the message header to discover who forwarded the message. Resent header fields are defined in section 3.6.6 of RFC 2822. When the history of the expansion of the distribution group must be transmitted.

Controlling Recipient Expansion

When the number of expanded recipients is too large, the categorizer splits the message into multiple copies. This is performed to reduce system resource use during message expansion. The maximum number of envelope recipients in a message is controlled by the ExpansionSizeLimit parameter in the EdgeTransport.exe.config application configuration file. The default value is 1000.

Caution: We recommend that you don't modify the value of the ExpansionSizeLimit parameter on an Exchange transport server in a production environment. Return to top

Recipient Resolution Diagnostics

Reporting and diagnostic information for recipient resolution is provided by performance counters, message tracking log entries, and recipient resolution logging. These sources can help you identify and diagnose problems with recipient resolution.

Recipient Resolution Performance Counters

The following table describes the performance counters that are available for recipient resolution.

Recipient resolution performance counters

Counter name Display name Ambiguous Recipients Description

AmbiguousRecipientsTotal

This is the total number of ambiguous recipients that were detected during recipient resolution. Ambiguous recipients are different recipients that have matching legacyExchangeDN Active Directory attributes or matching

proxyAddresses Active Directory attributes. AmbiguousSendersTotal Ambiguous Senders This is the number of ambiguous senders that were detected during recipient resolution. Ambiguous senders are different senders that have matching legacyExchangeDN Active Directory attributes or matching proxyAddresses Active Directory attributes. This is the number of failed recipients that were detected during recipient resolution.

FailedRecipientsTotal

Failed Recipients Loop Recipients Messages Chipped Messages Created Messages Retried Unresolved Org Recipients Unresolved Org Senders

LoopRecipientsTotal

This is the number of recipients that failed recipient resolution because of recipient loops.

MessagesChippedTotal

This is the total number of copies of the same message that were created during recipient resolution to control the number of envelope recipients in a single message. In Exchange 2010, this process is referred to as chipping. This is the number of messages that were created during recipient resolution.

MessagesCreatedTotal

MessagesRetriedTotal

This is the number of messages that were scheduled for retry during recipient resolution.

UnresolvedOrgRecipientsTotal

This is the number of unresolved recipients from an authoritative domain that were detected during recipient resolution.

UnresolvedOrgSendersTotal

This is the number of unresolved senders from an authoritative domain that were detected during recipient resolution.

Recipient Resolution Events That Are Written in the Message Tracking Log
The following table describes the recipient resolution events that are written in the message tracking log.

Recipient resolution events in the message tracking log

Message tracking event EXPAND REDIRECT Description

This event indicates that a distribution group was expanded. This event indicates that a message sent to a mailbox recipient or a mail-enabled public folder recipient was redirected to an alternative recipient as specified by the ForwardingAddress parameter. This event indicates that a recipient e-mail address was changed to the primary SMTP e-mail address of the corresponding Active Directory recipient object. This event indicates that message bifurcation or chipping occurred.

RESOLVE

TRANSFER

For more information about message tracking, see Understanding Message Tracking.

Recipient Resolution Logging

Recipient resolution logging is controlled by the ResolverLogLevel parameter in the EdgeTransport.exe.config application configuration file. The valid values for this parameter are Disabled, Enabled, and FullContent. The default value is Disabled. When the ResolverLogLevel parameter is set to Enabled, only message envelope data is logged. When the ResolverLogLevel parameter is set to FullContent, message envelope data and message header data is logged. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Remote Domains

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 You can create remote domain entries to define the settings for message transfer between the Microsoft Exchange Server 2010 organization and domains outside your Active Directory forest. When you create a remote domain entry, you control the types of messages that are sent to that domain. You can also apply message format policies and acceptable character sets for messages that are sent from users in your organization to the remote domain. The settings for remote domains are global configuration settings for the Exchange organization. The remote domain settings are applied to messages during categorization. When recipient resolution occurs, the recipient domain is matched against the configured remote domains. If a remote domain configuration blocks a specific message type from being sent to recipients in that domain, the message is deleted. If you specify a particular message format for the remote domain, the message headers and content are modified. Information about the remote domain configuration is stored in Active Directory. The settings apply to all messages that are processed by the Exchange organization. Note: If you configure message settings per user, the per-user settings override the organizational configuration. By default, there's a single remote domain entry. The domain address space is configured as an asterisk (*). This represents all domains. If you don't create additional remote domain entries, all messages that are sent to all recipients in all remote domains have the same settings applied to them. When you configure remote domains, you can prevent certain types of messages from being sent to that domain. These message types include out-of-office messages, auto-reply messages, non-delivery reports (NDRs), and meeting forward notifications. If you have a multiple forest environment, you may want to allow the sending of those types of messages to those domains. However, if you have identified a domain from which spam originates, you may want to block sending of those types of messages to those remote domains.

Message Format
You can specify the message format and the character set to use for e-mail messages that are sent to remote domains. These settings can be useful to make sure that e-mail sent by senders in your domain to the remote domain is compatible with the receiving e-mail system. For example, if you know that the remote domain's messaging system is Exchange, you can specify to always use Exchange rich text format (RTF). For more information, see Understanding Content Conversion.

Automatic Replies Settings

Automatic replies, formerly known as out-of-office replies, have changed substantially starting with Exchange Server 2007. In Exchange 2010 and Exchange 2007, users can specify different automatic replies for internal and external recipients. Furthermore, the types of automatic replies available in your organization also depend on the Microsoft Outlook version in use. In Exchange 2010, there are three types of automatic replies:

External Supported by Exchange 2010 and Exchange 2007. Can only be set by Outlook 2010 or Office Outlook 2007, or using Microsoft Office Outlook Web App. Internal Supported by Exchange 2010 and Exchange 2007. Can only be set by Outlook 2010 or Outlook 2007, or using Outlook Web App. Legacy Supported by Exchange 2010, Exchange 2007, and Exchange Server 2003. Can be set by Office Outlook 2003 or earlier. The following table describes various client and server combinations and the types of automatic replies that can be used in each scenario. Client and server support for automatic replies

Client version Outlook 2010 or Outlook 2007 Outlook Web App Outlook 2003 Outlook 2010, Outlook 2007, or Outlook 2003 Outlook Web Access

Exchange version Exchange 2010 Exchange 2007 Exchange 2010 Exchange 2007 Exchange 2010 Exchange 2007 Exchange 2003 Exchange 2003

Automatic replies supported Internal, External Internal, External Legacy Legacy Legacy

For a remote domain, you can specify one of the following options for sending automatic replies:

Allow none If you select this option, no automatic replies are sent to recipients in the remote domain. Allow external out-of-office messages only If you select this option, only External automatic replies are sent to the remote domain. Allow external out-of-office messages and legacy out-of-office messages (configured by using Outlook 2003 or earlier clients, or configured on Exchange 2003 mailboxes) If you select this option, both External and Legacy automatic replies are sent to the remote domain. Allow internal out-of-office messages, and legacy out-of-office messages (configured by using Outlook 2003 or earlier clients, or configured on Exchange 2003 mailboxes) If you select this option, both Internal and Legacy automatic replies are sent to the remote domain.

Controlling NDR Information

As mentioned at the beginning of this topic, you can prevent NDRs from being sent to a remote domain. By blocking NDRs to a remote domain, you can prevent the information contained within the NDR message from leaving your organization, thereby limiting the knowledge a malicious user can obtain about your organization. However, this also prevents legitimate senders from receiving NDRs, resulting in confusion and lost productivity. Exchange 2010 SP1 provides you with more granular control over the contents of an NDR destined for a remote domain. With Exchange 2010 SP1, you can now allow NDRs to a remote domain, while stripping any diagnostic information. This way, you can still prevent information about your Exchange deployment from leaving your organization while at the same time providing NDR notifications to external senders. This feature is controlled with the new NDRDiagnosticInfoEnabled parameter of the Set-RemoteDomain cmdlet. Because this setting is configurable for each remote domain, you can have different settings based on your needs. For example, you can choose to remove the NDR diagnostic information for the default remote domain, but allow full NDR diagnostic information for the remote domains that represent your partners. For more information about this new settings, see Set-RemoteDomain.

Remote Domains in Cross-Premises Deployments

Exchange 2010 SP1 supports cross-premises deployments where your Exchange organization is split between your on-premises servers and a cloud-based service such as Microsoft Office 365. In this deployment scenario, a remote domain object represents the part of your organization that exists in the cloud-based service. This remote domain is different from all the other remote domains you may have because it's considered an internal remote domain. You can use either the Shell or the EMC to designate a remote domain as your Office 365 deployment. For detailed steps, see Configure Remote Domain Properties.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Send Connectors

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 Send connectors are configured on computers that are running Microsoft Exchange Server 2010 and that have the Hub Transport server role or Edge Transport server role installed. The Send Connector represents a logical gateway through which outbound messages are sent. This topic provides an overview of Send connectors and explains how the configuration of Send connectors affects the processing of individual messages.

Overview of Send Connectors

Exchange 2010 transport servers require Send connectors to deliver messages to the next hop on the way to their destination. A Send connector controls outbound connections from the sending server to the receiving server or destination e-mail system. By default, no explicit Send connectors are created when the Hub Transport server role or the Edge Transport server role is installed. However, implicit and invisible Send connectors that are automatically computed based on the Active Directory site topology are used to route messages internally between Hub Transport servers. End-to-end mail flow is only possible after the Edge Transport server has been subscribed to the Active Directory site by using the Edge Subscription process. Other scenarios, such as an Internet-facing Hub Transport server or an unsubscribed Edge Transport server, require manual configuration of connectors to establish end-to-end mail flow. For more information, see Transport Server Post-Deployment Tasks. Send connectors that are created on Hub Transport servers are stored in Active Directory and are available to all Hub Transport servers in the organization. If a Send connector is configured to send messages to an external domain, any Hub Transport server in the organization will route a message for that domain to a source server for that connector to be relayed to the destination domain. The Send connector that's used to route messages to a recipient is selected during the routing resolution phase of message categorization. For more information, see Understanding Message Routing.

Selecting the Usage Type for a Send Connector

When you use the Exchange Management Console (EMC) to create a Send connector, the New SMTP Send Connector wizard prompts you to select a usage type for the connector. The usage type determines the default permission sets that are assigned on the connector and grants those permissions to trusted security principals. Security principals include users, computers, and security groups. A security principal is identified by a security identifier (SID). You can also specify a usage type when you create a Send connector by using the New-SendConnector cmdlet in the Exchange Management Shell. However, the Usage parameter isn't required. If you don't specify a usage type when you run the New-SendConnector cmdlet, the default usage type is set to Custom. The following table describes the Send connector usage types and their default settings. Send connector usage types

Type

Default permissions

SID that's granted the default permissions None

Default smart host authentication mechanism

Custom Internal

None

None Exchange Server Authentication

ms-Exch-SendHeadersOrganization ms-Exch-SMTPSend-Exch50 ms-Exch-SendHeaders-Routing ms-Exch-SendHeaders-Forest

Hub Transport servers Edge Transport servers Exchange Servers (on Hub Transport servers only) Externally Secured servers Exchange Legacy Interop universal security group Exchange Server 2003 and Exchange 2000 Server bridgehead servers

Internet

Ms-Exch-Send-HeadersRouting Ms-Exch-Send-HeadersRouting

Anonymous User Account

None

Partner

Partner Servers

Not applicable. This usage type is selected when you establish mutual Transport Layer Security (TLS) authentication with a remote domain.

Note: If Domain Name System (DNS) resolution delivery is selected for a Send connector instead of a smart host, no smart host authentication mechanism is configured. The Send connector permissions and smart host authentication mechanisms are discussed in detail later in this topic.

Send Connector Usage Scenarios

Each usage type is appropriate for a specific connection scenario. Select the usage type that has the default settings most applicable to the configuration that you want. You can modify permissions by using the Add-ADPermission and Remove-ADPermission cmdlets. For more information, see the following topics:

Add-ADPermission Remove-ADPermission The following table lists common connection scenarios and the usage type for each scenario. Connector usage scenarios

Connector scenario

Usage type Internet

Comment

Edge Transport server that sends e-mail to the Internet Hub Transport server that sends e-mail to the Internet A subscribed Edge Transport server that sends e-mail to a Hub Transport server Edge Transport server that sends e-mail to an Exchange 2003 bridgehead server Edge Transport server that sends e-mail to a Hub Transport server

A Send connector that's configured to send e-mail to all domains is created automatically when the Edge Transport server is subscribed to the Exchange organization. This isn't a recommended configuration. This connector is automatically created by the Edge Subscription process.

Internet Internal

Internal

The Exchange 2003 bridgehead server is configured as a smart host for the Send connector.

Custom

When the Edge Subscription process isn't used, a manual connector must be created. Use the Add-ADPermission cmdlet to set the extended rights. Set the authentication mechanism as Basic authentication or Externally Secured. For detailed configuration steps, see Configure Cross-Forest Connectors.

Cross-forest Send connector for a Hub Transport server in one forest that sends e-mail to an Exchange 2010 or Exchange 2007 Hub Transport server in a second forest Cross-forest Send connector for a Hub Transport server in one forest that sends e-mail to an Exchange 2003 bridgehead server in a second forest Hub Transport server that sends e-mail to a thirdparty smart host Edge Transport server that sends e-mail to a thirdparty smart host Edge Transport server that sends e-mail to an external relay domain

Custom

Custom

For detailed configuration steps, see Configure Cross-Forest Connectors.

Custom

Use the Add-ADPermission cmdlet to set the extended rights. Route all messages to a smart host and set the authentication mechanism to either Basic authentication or Externally Secured. Use the Add-ADPermission cmdlet to set the extended rights. Route all messages to a smart host and set the authentication mechanism to either Basic authentication or Externally Secured. The Edge Transport server can accept e-mail for an external relay domain and then relay the messages to the authoritative e-mail system for that domain. Route all messages to a smart host, set the appropriate authentication mechanism, and use the Add-ADPermission cmdlet to set the extended rights. Mutual TLS authentication functions correctly only if the following conditions are true: The value of the DomainSecureEnabled parameter must be $true. The value of the DNSRoutingEnabled parameter must be $true. The value of the IgnoreStartTLS parameter must be $false. For more information, see Set-SendConnector.

Custom

Custom

Edge Transport server that sends e-mail to a domain to which you have established mutual TLS authentication

Partner

Send Connector Permissions

You assign Send connector permissions to a security principal. When a security principal establishes a session with a Send connector, the Send connector permissions determine the types of header information that can be sent with the e-mail message. If an e-mail message includes header information that isn't allowed by the Send connector permissions, those headers are stripped from the message when it's sent. The following table describes the permissions that can be assigned on a Send connector to security principals. You can't set Send connector permissions by using the EMC. To modify the default permissions for a Send connector, you must use the Add-ADPermission cmdlet in the Shell. Send connector permissions

Send connector permission ms-Exch-SendExch50 Ms-Exch-SendHeaders-Routing Ms-Exch-SendHeadersOrganization

Description

This permission allows the session to send a message that contains the EXCH50 command. If this permission isn't granted, and a message is sent that contains the EXCH50 command, the server sends the message, but doesn't include the EXCH50 command. This permission allows the session to send a message that has all received headers intact. If this permission isn't granted, the server removes all received headers. This permission allows the session to send a message that has all organization headers intact. Organization headers all start with X-MSExchange-Organization-. If this permission isn't granted, the sending server removes all organization headers.

Ms-Exch-SendHeaders-Forest

This permission allows the session to send a message that has all forest headers intact. Forest headers all start with X-MS-Exchange-Forest-. If this permission isn't granted, the sending server removes all forest headers.

Address Spaces and Connector Scope

The address space for a Send connector specifies the recipient domains to which the Send connector will route e-mail. You can specify SMTP address spaces or nonSMTP address spaces on Send connectors that are configured on Hub Transport servers. You can only specify SMTP address spaces on Send connectors that are configured on Edge Transport servers. If you use a non-SMTP address space type, you must use a smart host to route e-mail. Note: Although you can configure non-SMTP address spaces on a Send connector on a Hub Transport server, the Send connector uses SMTP as the transport mechanism to send messages to other messaging servers. Delivery Agent connectors and foreign connectors on Hub Transport servers are used to send messages to nonSMTP local messaging servers, such as third-party fax gateway servers. For more information, see Understanding Delivery Agents and Understanding Foreign Connectors. The following table lists valid entries for the SMTP address space of a Send connector.

Valid entries for the SMTP address space of a Send connector

Address space entry * Send connector routes mail to:

All domains that don't have an explicit address space entry on another Send connector entry or that aren't an included subdomain of an address space on another Send connector. All recipients with e-mail addresses in the Contoso.com domain. All recipients with e-mail addresses in the Contoso.com domain or any subdomain of Contoso.com. In the EMC, select Include all subdomains to set this configuration. This address space is only used on Send connectors configured on Edge Transport servers for sending messages to the Hub Transport servers. When you use this address space, all messages addressed to your accepted domains are routed through this connector.

Contoso.com *.Contoso.com

--

During routing resolution, a Send connector, to which e-mail is routed for delivery to the destination address space, is selected. The Send connector whose address space most closely matches the recipient's e-mail address is selected. For example, an e-mail message addressed to Recipient@marketing.contoso.com would be routed through the connector that's configured to use the *.Contoso.com address space. When you configure a Send connector for a particular address space, e-mail sent to that address space is always routed through that connector. Also, the configuration settings for that connector are always applied to e-mail sent to that address space. You can use the scope of a Send connector to control the visibility of the Send connector within the Exchange organization. By default, all Send connectors that you create are usable by all the Hub Transport servers in the Exchange organization. However, you can limit the scope of any Send connector so that it's only usable by other Hub Transport servers that exist in the same Active Directory site. In Exchange 2010, the complete syntax for specifying an address space is as follows: <AddressSpaceType>:<AddressSpace>;<AddressSpaceCost> You can use the following methods to specify the scope of the Send connector:

In the EMC, use the Scoped Send connector property in the Address Space page of the New SMTP Send Connector wizard, or in the Address Space tab in the properties of an existing Send connector. When Scoped Send connector is selected, the connector can only be used by Hub Transport servers in the same Active Directory site. When Scoped Send connector isn't selected, the connector can be used by all Hub Transport servers in the Exchange organization. In the Shell, use the IsScopedConnector parameter in the New-SendConnector cmdlet or the Set-SendConnector cmdlet. When the value of this parameter is $true, the connector can only be used by Hub Transport servers in the same Active Directory site. When the value of this parameter is $false, the connector can be used by all Hub Transport servers in the Exchange organization.

Network Settings
You can set Send connectors so that they deliver e-mail by using DNS address resolution or by routing the e-mail to a smart host.

Using DNS to Route E-Mail

When the Send connector is set to use DNS MX resource records to route mail automatically, the DNS client on the source server must be able to resolve public DNS records. By default, the DNS server that's configured on the source server's internal network adapter is used for name resolution. You can configure a specific DNS server to use for internal and external DNS lookups by using the EMC to modify the DNS settings on the Exchange server properties. You can also use the Shell to configure the parameters in the Set-TransportServer cmdlet. If you configure a specific DNS server on the transport server to use for external DNS lookups, you must select Use the external DNS lookup settings on the transport server on the Network Settings page of the New SMTP Send Connector wizard or, in the Shell, on the Set-TransportServer cmdlet, set the UseExternalDNSServersEnabled parameter to $true. The DnsRoutingEnabled parameter on the Send connector must also be set to $true. For more information, see the following topics:

Configure Edge Transport Server Properties Configure Hub Transport Server Properties Set-TransportServer

Using a Smart Host to Route E-Mail

If you select the Internal usage type for the Send connector, you must specify a smart host. When you route mail through a smart host, the smart host handles delivery to the next hop in the delivery destination. You can use an IP address or the fully qualified domain name (FQDN) of the smart host to specify the smart host identity. The smart host identity can be the FQDN of a smart host server, an MX record, or an A (address) resource record. If you configure an FQDN as the smart host identity, the source server for the Send connector must be able to use DNS name resolution to locate the smart host server. The smart host for a Send connector with the Internet usage type may be a server that's hosted by your Internet service provider. The smart host for a Send Connector with the Custom or Internal usage types may be another e-mail server in your organization or an e-mail server in a remote domain.

Smart Host Security Settings

When you route mail through a smart host, you must specify how the source server will authenticate to the smart host computer. You can't require security settings for a Send connector unless a smart host destination is specified. For example, an Internet-facing connector can't be set to require TLS. The following table lists the smart host authentication mechanism that you can configure for a Send connector. Smart host authentication mechanisms

Security setting None Basic authentication Basic authentication over TLS

Description

Anonymous access is allowed. Basic authentication requires that you provide a user name and password. Basic authentication sends credentials in clear text. All smart hosts with which this Send connector is authenticating must accept the same user name and password. Select TLS to encrypt the transmission of the credentials. The receiving server must have a server certificate. The exact FQDN of the smart host, MX record, or A record that's defined on the Send connector as the smart host identity must also exist in the server certificate. The Send connector will attempt to establish the TLS session by sending the STARTTLS verb to the destination server and will only perform Basic authentication after the TLS session has been established. A client certificate is also required to support mutual TLS authentication. Exchange Server authentication (Generic Security Services application programming interface (GSSAPI) and Mutual GSSAPI)

Exchange Server authentication Externally Secured (for example, with IPsec)

The network connection is secured using a method that's external to the Exchange server.

Source Server
You must select at least one source server for a Send connector. The source server is the transport server to which messages are routed for delivery through the selected Send connector. You can set more than one source server on a Send connector that's configured for the Exchange organization. When you specify more than one source server, you provide load balancing and redundancy if a server fails. The source servers associated with Send connectors that are configured for the Exchange organization can be Hub Transport servers or subscribed Edge Transport servers.

FQDN
The General tab of the Send connector properties in the EMC includes the option Specify the FQDN this connector will provide in response to HELO or EHLO. In the Shell, this property is set by using the Fqdn parameter with the Set-SendConnector cmdlet. After an SMTP session is established, an SMTP protocol conversation starts between a sending e-mail server and a receiving e-mail server. The sending e-mail server or client sends the EHLO or HELO SMTP command and its FQDN to the receiving server. In response, the receiving server sends a success code and provides its own FQDN. In Exchange 2010, you can customize the FQDN that's provided by the sending server if you configure this property on a Send connector. The value of the Fqdn parameter is displayed to connected messaging servers whenever a source server name is required, as in the following examples:

In the most recent Received: header field of the message that's added to the message by the next hop messaging server after the message leaves the Hub Transport server or Edge Transport server During TLS authentication If the Send connector is configured on a Hub Transport server that also has the Mailbox server role installed, any value that you specify for the Fqdn parameter isn't used. Instead, the FQDN of the server that's displayed by using the Get-ExchangeServer cmdlet is always used. For servers that have both the Hub Transport server role and the Mailbox server role installed, the only way to remove the server name from the Received: headers of the outgoing message is to use the Remove-ADPermission cmdlet to remove the Ms-Exch-Send-Headers-Routing permission from the security principals that use the connector. This action will remove all the Received: headers from the message as the message leaves the Hub Transport server. We recommend that you don't remove the Received: headers for internal messages, because the Received: headers are used for maximum hop count calculations. For more information about the RemoveADPermission cmdlet and the Get-ExchangeServer cmdlet, see the following topics:

Remove-ADPermission Get-ExchangeServer

New Features in Exchange 2010 Service Pack 1

In Service Pack 1 (SP1) for Exchange Server 2010, new functionality was added to Send connectors. This section provides an overview of these new features.

Support for Downgrading Connection Failures

You may have dedicated Send connectors that are responsible for transmitting messages over well-defined communication channels that are expected to always be available, such as a Send connector dedicated to send messages to Microsoft Office 365 or to one of your partners over a private channel. On such connections, many of the typical errors that are possible on ordinary destinations on the Internet aren't expected. In this scenario, you may want to treat any communication errors as transient as opposed to issuing non-delivery reports (NDRs). With Exchange 2010 SP1, you can configure a Send connector to downgrade authentication and name resolution errors, which would normally result in an NDR, to transient errors. In these cases, Exchange will attempt delivery again instead of issuing an NDR. Downgrading connection failures over reliable connections give you an opportunity to troubleshoot and resolve problems without impacting your users. Important: This feature should only be enabled for Send connectors that transmit messages over well-defined and reliable networks. You shouldn't enable this feature for your Send connectors to the Internet. To configure this feature, you use the ErrorPolicies parameter of the Set-SendConnector cmdlet. You can choose to downgrade authentication failures, DNS failures or both for any Send connector. For more information about configuring this property, see Set-SendConnector.

Support for TLS Domain Validation

Exchange 2010 SP1 provides support for domain validation for outbound TLS connections. Domain validation is an additional security feature that reduces the risk of malicious users impersonating a receiving server. When you enable domain validation on a Send connector, the Transport server performs the following security checks on the outbound connection:

The communication channel is encrypted using TLS. The certificate of the receiving server is validated and revocation list checks are performed. The Transport server verifies that the FQDN on the certificate of the receiving server matches the domain configured in the Send connector properties. When you enable domain validation on a Send connector, you also have to specify the domain name to validate against. Both of these properties are configurable using the TlsAuthLevel and TlsDomain parameters of the Set-SendConnector cmdlet. For more information about configuring this feature, see Set-SendConnector.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Shadow Redundancy

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-19 High availability strategies for Exchange have focused on the availability and recoverability of data stored in mailbox databases. When you implement a highly available solution for your Mailbox servers, the e-mail messages won't be lost, and they can easily be recovered after a failure, after they arrive in a mailbox. However, these strategies didn't extend to messages while they're in transit. If a Hub Transport server fails while processing messages and can't be recovered, data loss could occur. As the volume of messages processed by Hub Transport servers increases, potential data loss becomes an increasing concern for administrators. Microsoft Exchange Server 2007 introduced the transport dumpster feature for the Hub Transport server role. An Exchange 2007 Hub Transport server maintains a queue of messages delivered recently to recipients whose mailboxes are on a clustered mailbox server. When a failover is experienced, the clustered mailbox server automatically requests every Hub Transport server in the Active Directory site to resubmit mail from the transport dumpster queue. This prevents mail from being lost during the time taken for the cluster to fail over. While this does provide a basic level of transport redundancy, it's only available for message delivery in a cluster continuous replication (CCR) environment and doesn't address potential message loss when messages are in transit between Hub Transport and Edge Transport servers. Exchange Server 2010 introduces the shadow redundancy feature to provide redundancy for messages for the entire time they're in transit. The solution involves a technique similar to the transport dumpster. With shadow redundancy, the deletion of a message from the transport databases is delayed until the transport server verifies that all of the next hops for that message have completed delivery. If any of the next hops fail before reporting back successful delivery, the message is resubmitted for delivery to that next hop. Shadow redundancy provides the following benefits:

It eliminates the reliance on the state of any specific Hub Transport or Edge Transport server. As long as redundant message paths exist in your routing topology, any transport server becomes disposable. If a transport server fails, you can remove it from production without emptying its queues or losing messages. If you want to upgrade a Hub Transport or Edge Transport server, you can bring that server offline at any time without the risk of losing messages. It eliminates the need for storage hardware redundancy for transport servers. It consumes less bandwidth than creating duplicate copies of messages on multiple servers. The only additional network traffic generated with shadow redundancy is the exchange of discard status between transport servers. Discard status is the information each transport server maintains. It indicates when a message is ready to be discarded from the transport database. It provides resilience and simplifies recovery from a transport server failure. Shadow redundancy is implemented by extending the SMTP service. The service extensions allow SMTP hosts to negotiate shadow redundancy support and exchange discard status for shadow messages. Looking for management tasks related to managing transport servers? See Managing Transport Servers.

Shadow Redundancy Components

The following table provides descriptions of all the components of shadow redundancy.

Shadow redundancy components

Component Primary message Shadow message Primary server Shadow server Shadow queue Description The original message submitted to transport for delivery. The copy of a message that a transport server retains until it confirms that all the next hops for that message have successfully delivered it. The transport server that's currently processing a message. The transport server that holds shadow copies of a message after delivering the message to the primary server. The queue that a transport server uses to store shadow messages. A transport server will have separate shadow queues for each hop to which it delivered the primary message. The information a transport server maintains for shadow messages that indicate when a message is ready to be discarded. The response a shadow server receives from a primary server indicating a message is ready to be discarded. The transport component that manages shadow redundancy.

Discard status Discard notification Shadow Redundancy Manager Heartbeat Return to top

The process of transport servers verifying the availability of each other.

Shadow Redundancy Message Flow

To illustrate the mail flow with shadow redundancy enabled, consider the simple scenario where a Hub Transport server sends a message to a third-party mail server via an Edge Transport server in the perimeter network.

Message flow with shadow redundancy

In this scenario, the message flow goes through following stages:

1. The Hub Transport server delivers a message to the Edge Transport server. a. The Hub Transport server opens an SMTP session with the Edge Transport server. b. The Edge Transport server advertises shadow redundancy support. c. The Hub Transport server notifies the Edge Transport server to track discard status. d. The Hub Transport server submits the message to the Edge Transport server. e. The Edge Transport server acknowledges the receipt of the message and records the Hub Transport server identity for sending discard information for the message. f. The Hub Transport server moves the message to the shadow queue for the Edge Transport server and marks the Edge Transport server as the primary server. The Hub Transport server becomes the shadow server. 2. The Edge Transport server delivers the message to the next hop. a. The Edge Transport server submits the message to a third-party mail server. b. The third-party mail server acknowledges the receipt of the message. c. The Edge Transport server updates the discard status for the message as delivery complete. 3. The Hub Transport server queries the Edge Transport server for discard status (success case). a. At the end of each SMTP session with the Edge Transport server, the Hub Transport server queries the Edge Transport server for discard status on messages previously submitted. If the Hub Transport server hasn't opened any SMTP sessions with the Edge Transport server after the initial message submission, it will open an SMTP session with the Edge Transport server just to query for the discard status after a specific amount of time. b. The Edge Transport server checks the local discard status and sends back the list of messages that have been delivered, and removes the discard information. c. The Hub Transport server deletes the list of messages from its shadow queue. 4. The Hub Transport server queries the Edge Transport server for the discard status and resubmits the message (failure case). a. If the Hub Transport server can't contact the Edge Transport server, the Hub Transport server resumes the primary server role and resubmits the messages in the shadow queue. b. Resubmitted messages are delivered to another Edge Transport server and the workflow starts from stage 1. Note: If there are no alternative routes available for a shadow message (such as the second Edge Transport server shown in the preceding figure), it won't be resubmitted, but remain in the shadow queue. For more information about message flow in various different scenarios, see Shadow Redundancy Mail Flow Scenarios.

Multiple Hop Scenario

If a message travels through multiple servers that support shadow redundancy, the shadow messages are retained on a server only until the next server in the message path confirms delivery. To illustrate how this works, consider an organization that has five Active Directory sites with Hub Transport servers installed. The sites are connected to each other as shown in the following figure. The organization has New York and London sites configured as hub sites, so the messages from Chicago or Atlanta need to go through Hub Transport servers in the New York and London sites to get to the Dublin site.

Assume that a message is sent by a user in the Chicago site to a user in the Dublin site. This message will need to travel through the New York and London sites to get to Dublin. In this case, the following occurs:

1. The Hub Transport server in Chicago will send the message to the Hub Transport server in New York, and it will retain a shadow copy of the message. 2. The New York Hub Transport server will send the message to the Hub Transport server in London and queue a discard status for the Chicago hub. 3. The Chicago hub queries the New York hub for discard status and receives the discard notification for the message. At this time, it can remove the shadow message from its database. Whether the message was delivered from London to Dublin doesn't have an impact on when the Chicago server deletes the shadow message.

Shadow Redundancy Protection when Hub Transport and Mailbox Server Roles Coexist with DAGs
When using database availability groups (DAGs), the messages that are already committed to mailbox databases are protected with the DAG architecture. For any message delivered to a mailbox database that's part of a DAG, the shadow copy for that message is retained in the transport dumpster until that message is replicated to all DAG members. Similarly, any message submitted to Hub Transport servers from a DAG member has two copies, one in the Hub Transport server queue waiting for delivery, and a shadow copy in the sender's Sent Items folder. This approach is a key component of shadow redundancy. However, when the Hub Transport and Mailbox server roles coexist on the same server, and you have mailbox databases that are part of a DAG, Hub Transport servers may have to route a message through an extra hop to avoid having the primary message and the shadow message on the same server hardware. Specifically, the Hub Transport server role attempts to avoid the following two scenarios because a failure of a single server may result in the loss of both the primary and shadow messages:

During message delivery, where the active mailbox database of the message recipient and the transport dumpster containing the shadow copy of the message are on the same server To avoid this scenario, the Hub Transport server routes the message through another Hub Transport server within the site to ensure that the shadow message ends up on different server hardware. However, if no other Hub Transport servers are available, it delivers the message directly. During message submission, where the transport queue holding the primary message and the shadow message in the Sent Items folder of the sender are on the same server To avoid this scenario, the store driver prefers other Hub Transport servers in the site for message submission. However, if no other Hub Transport servers are available in the site, it submits the message to the local Hub Transport server. For more information about Hub Transport and Mailbox server role coexistence when using DAGs, see Hub Transport and Mailbox Server Roles Coexistence When Using DAGs.

Interoperability
Whether shadow redundancy will be used or not is decided while establishing a new SMTP connection. If both servers in an SMTP connection support shadow redundancy, the workflow mentioned previously is used. However, there will be situations where Exchange 2010 transport servers exchange messages with mail servers that don't support shadow redundancy. These could be third-party mail servers, earlier versions of Exchange, or an Exchange 2010 organization that hasn't enabled shadow redundancy. When an Exchange 2010 transport server that supports shadow redundancy establishes a connection with a server that doesn't support shadow redundancy, the following events take place:

1. Exchange establishes an SMTP connection to the target server. 2. The target server doesn't advertise shadow redundancy support. 3. Because the target server doesn't support redundancy, Exchange will perform the following for each message: a. Deliver the message to the target server. b. Shadow Redundancy Manager will mark that the message is delivered to the next hop. c. Delete the message after it's delivered to all of the next hops. When a server that doesn't support shadow redundancy establishes a connection with an Exchange 2010 server, the following events take place:

1. 2. 3. 4.

The sending server establishes an SMTP connection with Exchange. Exchange advertises shadow redundancy support. The sending server doesn't support shadow redundancy and therefore it won't use it. It will deliver messages to the Exchange server. For each message Exchange receives, it will do the following: a. Deliver the message to the next hop, or make a shadow copy of it. b. Send acknowledgement to the sending server.

Delayed Acknowledgement
The main principle behind shadow redundancy is maintaining a copy of the message on the previous hop until the server verifies that it has successfully delivered it to all the next hops. This isn't possible when an Exchange 2010 transport server is receiving a message from a mail server that doesn't support shadow redundancy. This mail server can be an Exchange server running an older version of Exchange, a standard SMTP client, or a non-Exchange mail server on the Internet. In this case, Exchange attempts to achieve shadow redundancy by delaying the acknowledgement to the mail server until it verifies that the message has been successfully delivered to all the next hops internally. This way, if the Exchange 2010 server fails, the sending mail server will assume that the message was never delivered to Exchange and will attempt delivery again. However, the delivery of the message to the next hops may take a long time due to the complexity of your routing infrastructure, or failure of one of the next hops. In this case, to prevent the SMTP session from timing out, the Exchange 2010 transport server will send an acknowledgement to the sending mail server. In this case, the mail redundancy isn't guaranteed, but it's a best effort. For example, a message may be lost in the following scenario: An Internet mail server transmits a message to an Edge Transport server. The Edge Transport server can't communicate with the Hub Transport server due to a network problem and acknowledges the receipt of the message to the Internet mail server. The Edge Transport server then fails and can't be recovered before the network problem is resolved. At this point, the message is lost. The delayed acknowledgement time-out value is controlled by the MaxAcknowledgementDelay attribute of each Receive connector. The default value is 30 seconds. To learn more about configuring this attribute, see Configure Shadow Redundancy.

Bypassing Delayed Acknowledgement

There are cases where it's unlikely a message will be delivered before the delayed acknowledgement time-out is reached. In these cases, the transport server uses one of the following methods to handle messages:

Skipping delayed acknowledgement By default, the transport server skips the delayed acknowledgement to maintain SMTP receive throughput. In essence, the transport server issues an acknowledgment before the time-out is reached. Shadow redundancy promotion In Microsoft Exchange Server 2010 Service Pack 1 (SP1), instead of skipping the delayed acknowledgement, the transport server can be configured to relay the message to any other transport server in the site. This effectively inserts the message into the shadow redundancy pipeline, thereby protecting the message. This process is called shadow redundancy promotion. This approach minimizes the number of unprotected messages in the organization when compared to the skipping delayed acknowledgement method. By default, this feature is disabled. To enable shadow redundancy promotion, an administrator must edit the Edgetransport.exe.config file, change the shadowredundancypromotionenabled key to true, save the changes to the file, and then restart the Microsoft Exchange Transport service MSExchangeTransport.exe. For more information about how to do this, see the Enable Shadow Redundancy Promotion section in the Configure Shadow Redundancy topic. The following table lists different scenarios ion which a transport server bypasses delayed acknowledgement, and describes how an Exchange 2010 server handles that scenario.

Scenario

Exchange 2010 default behavior (skipping delayed acknowledgement)

Exchange 2010 SP1 with shadow redundancy promotion enabled

The target queue for the message is either in suspended or retry state. The target queue enters retry state after the message is added to it. An administrator suspends either the target queue or the message. The target queue for the message has more than 100 messages. Return to top

The receiving transport server skips the delayed acknowledgement.

The receiving transport server immediately uses shadow redundancy promotion.

The receiving transport server skips the delayed acknowledgement for subsequent messages until the target queue returns to ready state.

The receiving transport server uses shadow redundancy promotion for subsequent messages until the target queue returns to ready state.

If the administrator suspends the target queue, the receiving transport server skips the delayed acknowledgement until the target queue returns to ready state. If the administrator suspends the message, the receiving transport server handles subsequent messages normally. The receiving transport server skips the delayed acknowledgement until the target queue size falls below 100.

If the administrator suspends the target queue, the receiving transport server uses shadow redundancy promotion until the target queue returns to ready state. If the administrator suspends the message, the receiving transport server handles subsequent messages normally. If the target queue has any messages in it, the receiving transport server uses shadow redundancy promotion for subsequent messages until the queue clears.

Shadow Redundancy Manager

Shadow Redundancy Manager is the core component of an Exchange 2010 transport server that's responsible for managing shadow redundancy. Shadow Redundancy Manager is responsible for maintaining the following information for all the primary messages that a server is currently processing:

The shadow server for each primary message being processed. The discard status to be sent to shadow servers. Shadow Redundancy Manager is responsible for the following for all the shadow messages that a server has in its shadow queues:

Maintaining the list of primary servers for each shadow message. Checking the availability of each primary server for which a shadow message is queued. Processing discard notifications from primary servers. Removing the shadow messages from the database after all expected discard notifications are received. Deciding when the shadow server should take ownership of shadow messages, becoming a primary server. In addition, Shadow Redundancy Manager is also responsible for managing performance counters related to shadow redundancy.

Heartbeat
Shadow Redundancy Manager uses heartbeat to determine the availability of the servers for which shadow messages are queued. During the SMTP session between two servers that both support shadow redundancy, the server that initiates the connection queries the target server for discard status of messages previously submitted to that server. The initiating server accomplishes this by issuing an XQUERYDISCARD command. In response, the target server returns the discard notifications. This exchange between the two servers is used as the heartbeat for shadow redundancy. There is a time-out value for the heartbeat. If no connections are established to a server for which Shadow Redundancy Manager is maintaining a shadow queue for that duration, the server will attempt to establish an SMTP connection with the primary server specifically to query the discard status and reset the timer. The time-out value is controlled by the ShadowHeartbeatTimeoutInterval parameter of the Set-TransportConfig cmdlet. The default value for this parameter is 300 seconds in the release to manufacture (RTM) version of Exchange 2010, and 900 seconds in Exchange 2010 SP1. If the server can't establish a connection to a primary server when the time-out value is reached, it will reset the timer and try again. If the time-out value is reached twelve times in a row (three times in a row in Exchange 2010 RTM), the server will conclude that the primary server has failed and will assume ownership of the shadow messages and begin to generate discard notifications for them to send to the primary server that failed. The number of time-outs a server will wait before deciding a primary server has failed is controlled by the ShadowHeartbeatRetryCount parameter of the Set-TransportConfig cmdlet. To learn more about configuring the shadow redundancy heartbeat, see Configure Shadow Redundancy. Return to top

Message Processing After an Outage

Shadow redundancy minimizes message loss due to server outages. When a transport server comes back online after an outage, there are two scenarios:

The server comes back online with a new transport database In this scenario, the transport database is unrecoverable due to data corruption or hardware failure. In this case, because the transport server will have a new database ID, it will be recognized as a new route by the other transport servers in the organization. This also applies to the situation where a server couldn't be recovered, and a new server was provisioned as a replacement. The server comes back online with the same transport database In this scenario, the particular transport server didn't fail, but was offline for an extended period of time. For example, a network card failure, or a long maintenance on the server would cause this scenario.

The following table summarizes how transport reacts to these two scenarios when shadow redundancy is enabled. For clarity, assume that the server that had an outage is named Hub01.

Message processing in recovery scenarios

Recovery scenario Hub01 comes back online with a new database. Hub01 comes back online with the same database. Actions taken for messages that have alternative routes Actions taken for messages with no alternative routes

When Hub01 becomes unavailable, each server that has shadow messages queued for Hub01 will assume ownership of those messages and resubmit them. The messages then get delivered to their destinations using alternative routes. The total delay for messages is equal to the product of the heartbeat time-out interval and the heartbeat retry count configured in your organization. Hub01 will deliver the messages in its queues. This will result in duplicate delivery of these messages. Exchange mailbox users won't see duplicate messages due to duplicate message detection. However, recipients on foreign systems may receive duplicate copies. The total delay for messages is equal to the product of the heartbeat time-out interval and the heartbeat retry count configured in your organization.

These messages remain in the shadow queue on each server that has shadow messages queued for Hub01. When Hub01 comes back online with a new database ID, the shadow servers detect that it's a new database and resubmit the messages that are in the shadow queue to Hub01. This is equivalent to suddenly discovering an alternative route for these messages. The total delay for the messages depends on the duration of the outage.

Hub 01 will deliver the messages in its queues and then send discard notifications to the shadow servers. The total delay for the messages depends on the duration of the outage.

Return to top

Extended Rights Required for Shadow Redundancy

Exchange 2010 introduces the following two extended rights, which are required for shadow redundancy:

ms-Exch-SMTP-Accept-XSHADOW ms-Exch-SMTP-Send-XSHADOW When an SMTP connection is established to an Exchange 2010 transport server, it will advertise shadow redundancy support if the ms-Exch-SMTP-Accept-XSHADOW extended right exists on the Receive connector being used. In addition, the authentication mechanism on the Receive connector should be either Exchange Server authentication or Externally Secured. When an Exchange 2010 transport server establishes an SMTP connection to another server that advertises shadow redundancy support, it will issue an XSHADOW command only if the session has been granted the ms-Exch-SMTP-Send-XSHADOW extended right. By default, these extended rights are granted to the Exchange Servers group on all internal Send connectors and Receive connectors. Note: Shadow redundancy can be enabled or disabled for the entire organization using the ShadowRedundancyEnabled parameter of the Set-TransportConfig cmdlet. This setting overrides the extended rights described in this section. If shadow redundancy is disabled for the organization, Exchange will never advertise shadow redundancy support or issue XSHADOW commands even if the necessary extended rights are granted to the SMTP session. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Shadow Redundancy Mail Flow Scenarios

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-06-07 The shadow redundancy feature in Microsoft Exchange Server 2010 provides redundancy for messages for the entire time they're in transit. The general message flow is explained in Understanding Shadow Redundancy. This topic explains in detail what happens for each specific message flow scenario that can involve Exchange.

Mail Flow Scenarios

The following figure shows each possible redundancy scenario in an Exchange organization and how message redundancy is achieved in each scenario. The shaded area shows where shadow redundancy is in effect. Exchange 2010 shadow redundancy prevents data loss while messages are in transit within the shaded area. Note: Client Access servers are omitted from the figure for simplicity.

As can be seen from the preceding figure, all mail flow paths possible in an Exchange organization fit into one of the following scenarios: A. MAPI/Windows Mobile Client Submission B. Mail Flow from Mailbox Server to Hub Transport Server C. Message Delivery from Hub Transport Server to Mailbox Server D. Mail Flow Between Exchange 2010 Transport Servers E. Mail Flow from Exchange 2010 Transport Servers to Mail Servers That Don't Support Shadow Redundancy F. Mail Flow from Mail Servers That Don't Support Shadow Redundancy to Exchange 2010 Transport Servers The following sections explain what happens for each mail flow scenario.

A. MAPI/Windows Mobile Client Submission

Message submissions from MAPI or Windows Mobile clients aren't redundant. After the message is successfully stored on the Mailbox server, Exchange high availability features can take effect and help prevent data loss. This scenario provides a complete picture of message flow, from beginning to end. Return to the list of mail flow scenarios

B. Mail Flow from Mailbox Server to Hub Transport Server

The following actions take place when an Exchange 2010 Mailbox server submits messages to an Exchange 2010 Hub Transport server. Important: Exchange 2010 Mailbox servers can't communicate with transport servers running previous versions of Exchange. Therefore, this topic only discusses mail flow from an Exchange 2010 Mailbox server to an Exchange 2010 Hub Transport server. 1. The mail submission service notifies the Hub Transport server that there is a new message. 2. The Hub Transport server picks up the message from the Outbox of the mailbox submitting the message and stores it in its database.

3. If the message has recipients on Mailbox servers that are in the same Active Directory site, the Hub Transport server delivers the message to the destination mailboxes, following the steps listed in scenario C. For all other recipients, the Hub Transport server delivers the message to the next hop. 4. After delivery to the next hop is complete, the Hub Transport server notifies the Mailbox server that it has finished processing the message and assumed ownership of the message. After this notification, the message is deleted from the Outbox. 5. If none of the other hops for the message support shadow redundancy, the Hub Transport server deletes the message. Otherwise, it converts the message to a shadow message by storing it in the shadow queues for the hops to which it delivered the message. Return to the list of mail flow scenarios

C. Message Delivery from Hub Transport Server to Mailbox Server

The following actions take place when an Exchange 2010 Hub Transport server delivers messages to an Exchange 2010 Mailbox server. Important: Exchange 2010 Hub Transport servers can't communicate with Mailbox servers running previous versions of Exchange. Therefore, this topic only discusses mail flow from an Exchange 2010 Hub Transport server to an Exchange 2010 Mailbox server. 1. The Hub Transport server delivers the message to the destination mailboxes. 2. After the message is delivered to all the destination mailboxes, the Hub Transport server adds the message to the transport dumpster. 3. The Hub Transport server queues discard notifications to the hop from which it has received the message. These discard notifications are created when the hop queries the Hub Transport server. 4. The previous hop deletes the corresponding shadow message. Return to the list of mail flow scenarios

D. Mail Flow between Exchange 2010 Transport Servers

The mail flow process is identical for all message exchanges between transport servers running Exchange 2010, whether it's between two Hub Transport servers or between a Hub Transport server and an Edge Transport server. The following actions take place when a message is transferred from one Exchange 2010 transport server to another. For clarity purposes, assume that the server that's sending the message is called Hub01 and the server that's receiving the message is called Edge01.

1. Hub01 establishes an SMTP connection to Edge01. 2. Edge01 advertises shadow redundancy support. 3. Hub01 requests shadow redundancy in the SMTP session by issuing an XSHADOW command. The process is similar to establishing Transport Layer Security (TLS) on an SMTP session. 4. For each message that Hub01 needs to send to Edge01: a. Hub01 transmits the message to Edge01. b. Edge01 marks the message as shadowed by Hub01. c. Hub01 marks Edge01 as the primary server and adds it to its shadow queue for Edge01. d. Hub01 prepares discard notifications for the message to be sent to the hop from which it received the message. 5. Hub01 queries Edge01 for discard status of messages it has previously submitted to Edge01. 6. Edge01 sends all discard notifications that it has prepared for Hub01. These could be for messages that are sent in the same SMTP session or for those that were sent during previous SMTP sessions. 7. Hub01 deletes all shadow messages for which Edge01 has sent a discard notification. Return to the list of mail flow scenarios

E. Mail Flow from Exchange 2010 Transport Servers to Mail Servers That Don't Support Shadow Redundancy
Neither Exchange Server 2007 transport servers nor Exchange Server 2003 bridgehead servers support shadow redundancy. Therefore, if you have a coexistence scenario with previous versions of Exchange, Exchange 2010 redundancy features can guarantee message delivery only until the legacy Exchange hop, and not all the way to its destination. The same applies to the scenario where Exchange 2010 Edge Transport servers send messages to non-Exchange mail servers. The following actions take place when an Exchange 2010 Hub Transport server sends a message to an Exchange transport server running a previous version of Exchange, or an Exchange 2010 Edge Transport server sends a message to a non-Exchange mail server. For clarity, assume that an Exchange 2010 Hub Transport server called Hub01 is sending a message to an older Exchange transport server called Legacy01.

1. 2. 3. 4. 5. 6.

Hub01 establishes an SMTP connection to Legacy01. Legacy01 doesn't advertise shadow redundancy support. Because Legacy01 didn't advertise shadow redundancy, Hub01 doesn't initiate shadow redundancy on the SMTP session. Hub01 delivers the message to Legacy01. Hub01 deletes the message. Hub01 prepares discard notifications for the hop from which it received the message.

Return to the list of mail flow scenarios

F. Mail Flow from Mail Servers That Don't Support Shadow Redundancy to Exchange 2010 Transport Servers
There are four entry points to an Exchange organization where a mail server that doesn't support shadow redundancy may establish an SMTP connection to an Exchange 2010 transport server and send messages.

An Exchange 2010 Unified Messaging (UM) server connecting to an Exchange 2010 Hub Transport server. An Exchange transport server that's running Exchange 2007 or Exchange 2003 connecting to an Exchange 2010 Hub Transport server. A non-Exchange mail server on the Internet connecting to an Exchange 2010 Edge Transport server. A non-Exchange mail server in the organization, such as a UNIX server, or an SMTP client that's submitting messages to an Exchange 2010 Hub Transport server. In this scenario, Exchange 2010 achieves shadow redundancy using a feature called delayed acknowledgement. When an Exchange 2010 transport server receives a message from a mail server that doesn't support shadow redundancy, it delays sending an acknowledgement to the sending mail server until it has confirmed that the message has been successfully delivered to its destination. For more information about delayed acknowledgement, see Understanding Shadow Redundancy. To illustrate this scenario, assume that an Exchange 2010 Edge Transport server called Edge01 is receiving a message from a non-Exchange mail server on the Internet called Internet01. In this example, the following actions take place:

1. 2. 3. 4. 5. 6. 7. 8.

Internet01 establishes an SMTP connection to Edge01. Edge01 advertises shadow redundancy support. Because Internet01 doesn't support shadow redundancy, it simply sends the message to Edge01. Edge01 marks the message as a delayed acknowledgement message. Edge01 delivers the message to the next hops using the steps outlined in scenario D. Edge01 queries the next hops for the discard status of the message. After Edge01 receives discard notifications from all of the next hops, it sends the acknowledgement to Internet01. Edge01 deletes the message from its database. Note: If Edge01 can't verify successful delivery of the message to all of the next hops within 30 seconds, it will time out and send an acknowledgement to Internet01. This time-out value is controlled by the value of the MaxAcknowledgementDelay attribute of the Receive connector.

Return to the list of mail flow scenarios

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Hub Transport and Mailbox Server Roles Coexistence When Using DAGs
Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-07-19 Microsoft Exchange Server 2007 doesn't support Hub Transport and Mailbox server roles on the same server hardware when high availability features such as single copy cluster (SCC) or cluster continuous replication (CCR) are used. A minimum high availability deployment in Exchange 2007 requires four servers: two nodes for mailbox high availability and two Hub Transport servers for message transfer redundancy. To reduce the number of servers required to provide a high availability solution, Exchange Server 2010 supports Hub Transport and Mailbox server roles on the same server hardware when using database availability groups (DAGs). Exchange 2010 provides a feature called shadow redundancy, which protects against data loss while messages are in transit. When used together, DAGs and shadow redundancy offer a highly resilient messaging infrastructure. This topic focuses on how the Exchange 2010 Hub Transport server role behaves when deployed on the same server hardware as a Mailbox server that participates in a DAG. To learn more about DAGs, see Understanding Database Availability Groups.

Message Submission and Delivery

Shadow redundancy prevents data loss while messages are in transit by keeping a duplicate copy of the message along the message path. If a message is lost in transit due to a failure, the shadow copy of the message is resubmitted by the Transport component. For detailed information about how shadow redundancy is implemented, see Understanding Shadow Redundancy. Mailbox servers are involved during initial message submission, when a user clicks Send, and during final delivery, when the message is saved to the Inbox of the recipient. When a message is submitted to Transport, the primary copy of that message is in the queues of the Hub Transport server to which the message was submitted. The shadow copy of that message is the item stored in the Sent Items folder of the sender. When a message is delivered, the primary copy is in the recipient's Inbox and the shadow copy of the message is stored in the transport dumpster. In a high availability scenario where Hub Transport and Mailbox server roles coexist on the same server hardware, it's crucial to try to avoid having both copies of a message reside on the same server. Consider the deployment scenario shown in the following figure. The topology consists of two Exchange servers participating in a DAG with the Hub Transport server role installed. The databases DB1 and DB2 are part of the DAG. Active databases are shown in green, and passive databases are shown in blue.

In this topology, assume that a user whose mailbox is on DB1 sends a message. If that message is submitted to the Hub Transport server role on Server1, both the primary and shadow messages will be physically stored on Server1. The primary messages will be in the Hub Transport server queues, and the shadow messages will be in the Sent Items folder of the sender, as shown in the following figure.

Similarly, if the Hub Transport server role on Server1 receives a message destined to a user on DB1, the message is delivered directly, and both the primary and shadow messages will be physically stored on Server1. The primary messages will be in the Inbox of the recipient, and the shadow messages will be in the transport dumpster, as shown in the following figure. If a server failure occurs at either of those instances, there's a chance that the message can be lost.

To avoid these scenarios where message loss can occur, Exchange attempts to submit or deliver messages over a route that ensures that the primary and shadow

copies of messages are stored on different physical servers. The modified message submission and delivery behaviors are discussed in the following section.

Message Submission Behavior

When a user whose mailbox is in a database that's a member of a DAG sends a message, the mail submission service gives preference to remote Hub Transport servers if it detects that the Hub Transport server is also installed on the local server. As shown in the figure "Two server high availability topology with Hub Transport and Mailbox server roles", if a user whose mailbox is on DB1 sends a message, the mail submission service will attempt to use the Hub Transport server installed on Server2 for message submission. The following figure shows this preferred message submission path.

In the case where no other Hub Transport servers are available in the site (for example, if Server2 is unavailable due to scheduled maintenance), the message submission service will fall back to submitting the message to the local Hub Transport server. Even though this is an undesirable submission path for redundancy, Exchange won't delay delivery of messages. This fallback submission path is desirable for availability and low delivery latency.

Message Delivery Behavior

The message routing and delivery behavior doesnt change in most cases. For example, if Server1 shown in the figure "Two server high availability topology with Hub Transport and Mailbox server roles" receives a message for a recipient on DB2, it will deliver the message normally because that database is active on a different server. The only scenario when a Hub Transport server will process an incoming message differently is when the target mailbox is on a database that's part of a DAG and is also active on the local server. Because a direct delivery in this situation would result in both the delivered message and the copy in the transport dumpster being on the same server, the Hub Transport server will instead reroute this message to another Hub Transport server within the same site. The following figure shows the message delivery path in this scenario.

In the case where no other Hub Transport servers are available in the site, the Hub Transport server will fall back to local delivery even though it's an undesirable delivery path for redundancy. Again, this fallback delivery path is desirable for availability and low delivery latency.

Message Flow Scenarios

This section explains in detail what happens in various message flow scenarios when Hub Transport and Mailbox server roles coexist on the same server. The topology shown in the following figure is used to illustrate various possible message flow scenarios.

The following table shows how the Hub Transport server role on Server1 processes messages in various scenarios. In all of these cases, Server1 is considered the entry point.

Sender location DB1, active on Server1

Recipient location DB1, active on Server1

Normal message path

High availability scenarios

1. Submission service on Server1 submits a message to the Hub Transport server role on Server2. 2. Hub Transport server role on Server2 delivers the message to DB1 on Server1 and adds the message to the transport dumpster on Server2.

If Server1 fails before the message submission completes, the message in the sender's Outbox may be lost. If Server2 fails before the message submission completes, the message is submitted to the Hub Transport server role on Server1. If Server1 fails after the message submission to the Hub Transport server role on Server2 completes, DB1 will become active on Server2. The message will be queued on Server2 until DB1 is mounted, and then the Hub Transport server role delivers the message locally. If Server2 fails after the message submission to Hub Transport server role on Server2 completes, the shadow message in DB1 is resubmitted to the Hub Transport server role on Server1, which delivers the message locally. If Server1 fails after the message delivery is completed, DB1 will become active on Server2. If the delivered message hasn't yet been committed to the database, it's redelivered from the transport dumpster on Server2.

DB1, active on Server1

DB2, active on Server2

1. Submission service on Server1 submits the message to the Hub Transport server role on Server2. 2. Hub Transport server role on Server2 reroutes the message to the Hub Transport server role on Server1. 3. Hub Transport server role on Server1 delivers the message to DB2 on Server2 and adds the message to the transport dumpster on Server1.

Any server failures prior to the completion of message submission are handled in the same manner as described in the previous row. If Server1 fails after the message submission to the Hub Transport server role on Server2 completes, the Hub Transport server role on Server2 will deliver the message locally. If Server2 fails after the message submission to the Hub Transport server role on Server2 completes, DB2 will become active on Server1. After the Hub Transport server role on Server1 detects that the Hub Transport server role on Server2 is unavailable, it will resubmit the shadow message. After DB2 is mounted on Server1, the message will be delivered locally. If Server1 fails after the message is rerouted to Server1 for delivery, the Hub Transport server role on Server2 will resubmit the shadow message after it detects the Hub Transport server role on Server1 is unavailable. It will then deliver the message locally. If Server2 fails after the message is rerouted to Server1 for delivery, DB2 will become active on Server1. The message will remain queued on Server1 until DB2 is mounted on Server1 and then it's delivered locally. If Server2 fails after the message delivery is completed, DB2 will become active on Server1. If the delivered message hasn't yet been committed to the database, it's redelivered from the transport dumpster on Server1.

External

DB1, active on Server1

1. Hub Transport server role on Server1 reroutes the message to the Hub Transport server role on Server2. 2. Hub Transport server role on Server2 delivers the message to DB1 on Server1 and adds the message to the transport dumpster on Server2.

If Server1 fails before it completes receiving the message from Edge1, Edge1 will attempt delivery to the Hub Transport server role on Server2. If Server1 fails after it completes receiving the message from Edge1, Edge1 will resubmit the message to the Hub Transport server role on Server2 after it detects that the Hub Transport server role on Server1 is unavailable. The Hub Transport server role on Server2 will then deliver the message locally after DB1 is mounted on Server2. All other failure scenarios are handled in the same manner as described in the first row.

External

DB2, active on Server2

1. Hub Transport server role on Server1 delivers the message to DB2 on Server2, and adds the message to the transport dumpster on Server1.

If Server1 fails before it completes receiving the message from Edge1, Edge1 will attempt delivery to the Hub Transport server role on Server2. If Server1 fails after it completes receiving the message from Edge1, but before delivering to DB2 on Server2, Edge1 will resubmit the shadow message to the Hub Transport server role on Server2. This is because Server1 won't send an acknowledgement to Edge1 until it successfully delivers the message to DB2. Because Edge1 hasn't received an acknowledgement, it will resubmit the message after it detects that Server1 is unavailable. If Server2 fails after message delivery is completed, DB2 will become active on Server1. If the delivered message hasn't yet been committed to the database, it's redelivered from the transport dumpster on Server1.

The preceding table focuses on the minimum scenario where there are only two Hub Transport servers in a site that both coexist with Mailbox server roles that participate in DAGs. In more complex deployments where additional dedicated Hub Transport servers are available, those servers are also used when making routing decisions. However, if you have a large enough deployment where you can employ dedicated Hub Transport servers, it's a best practice to not install the Hub Transport server role on Mailbox servers that participate in a DAG.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding TLS Certificates

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-11-04 In cryptographic terms, the certificate and related private keys that are generated by the New-ExchangeCertificate cmdlet are TLS keys. The New-ExchangeCertificate cmdlet lets you specify metadata about the certificate so that different services can use the same certificate and private key. Before you create certificates or certificate requests for Exchange services that use TLS, you should understand the metadata that are used by the certificates for SSL and TLS services. This metadata is referred to as "fields" in the resulting certificate. To view the fields of computer certificates on a specific computer, you can use the Get-ExchangeCertificate cmdlet in the Exchange Management Shell. Alternatively, you can use the Certificate Manager snap-in in the Microsoft Management Console (MMC). Looking for management tasks related to TLS certificates? See Certificates. Contents Fields Used by Certificates for TLS Services Certificate Selection Creating TLS Certificates References

Fields Used by Certificates for TLS Services

If you're using the New-ExchangeCertificate cmdlet to generate a certificate request from a third-party or other public key infrastructure (PKI) certification authority (CA), make sure that you validate which certificate fields and certificate format are required by the CA. This section explains the most important certificate fields and provides some best practices for generating certificates and certificate requests.

Subject Name
The Subject Name of a TLS certificate is the field that is used by DNS-aware services. The Subject Name field binds a certificate to a particular server or domain name. A subject name is an X.500 distinguished name that consists of one or more relative distinguished names, also known as RDN. The following table lists the frequently used relative distinguished names for identifying organizations or server entities.

Name Country/Region Domain Component State or Province Locality Organization Organizational Unit Common Name

Abbreviation C DC S L O OU CN

Type ASCII ASCII Unicode Unicode Unicode Unicode Unicode

Max Size 2 255 128 128 64 64 64

Frequency Max.\Recommended in certificate\request 1\1 Many 1 1 1\1 Many\Many Many\1

Order in subject 1 1 2 3 4 5 6

The Country/Region codes are the ISO 3166-1 codes. For more information, see English country names and code elements. Domain Component and Country/Region are by convention mutually exclusive. It's a best practice to reference the name by Country/Region or reference the name by Domain Name System (DNS) name. Also, be aware that the maximum size of the Domain Component (255 characters) is the total of all Domain Component values. Important: Although certificates can have more than one common name field, some services are implemented on the assumption that there is only one common name. Therefore, multiple common names can cause interoperability issues. We recommend that the certificate or certificate request that you create contains only one common name.

Specifying Relative Distinguished Names

When creating certificate requests using the New-ExchangeCertificate cmdlet, subject names are represented as a single parameter that consists of a series of comma-separated names. Each name is identified by the abbreviation for the relative distinguished name. For example, the following subject name represents Country/Region = US, Organization = Contoso Corp, and Common Name = mail1.contoso.com:

-SubjectName "C=US o=contoso corp, CN=mail1.contoso.com"

Other examples of subject names that can represent the same server include the following examples:

-SubjectName "O=contoso corp, CN=mail1.contoso.com" -SubjectName "DC=contoso, DC=com, CN=mail1.contoso.com" -SubjectName "DC= contoso, DC=com, O=contoso corp, CN=mail1.contoso.com"

If you have a registered DNS name that you use to send SMTP mail, it's a best practice to use the domain component convention and the DNS name for the certificate name, such as DC=contoso, DC=com, CN=mail1.contoso.com. However, when you generate a certificate request for a CA provider, you must understand the Subject Name field requirements of the CA and your unique PKI needs. In some cases, you may have to use the Country/Region code ("C"). If that's the case, you must register your relative distinguished name with an X.500 registration authority.

International Subject Names

For subject names that contain non-ASCII characters, you can enter the SubjectName parameter as a distinguished name enclosed in quotation marks, as follows: -SubjectName "C=ES,O=Diversin de Bicicleta,CN=mail1. DiversiondeBicicleta.com"

Subject Names and Domain Names

By convention, a common name can contain a fully qualified domain name (FQDN). Although this practice is widespread, be aware of the following two issues with this approach. First, the maximum size of the Common Name field is 64 characters. This is fewer characters than the maximum size of a FQDN. Therefore, for FQDNs that are more than 64 characters, you must put the domain name in the Subject Alternative Name. The DomainName parameter is the parameter that maps to the Subject Alternative Name on the resulting certificate. Second, the FQDN is restricted to a subset of the ASCII character set. However, the common name (CN) supports Unicode. Therefore, you can create a valid certificate with a CN that seems like a DNS name but is an invalid DNS name. Software that is looking for a FQDN in a certificate CN will not return the correct result if the CN contains non-ASCII characters. For example, if you create a certificate with a Subject Name where CN=mail.mcrosoft.com, the name would be ignored as a FQDN because the name contains a Unicode character the character with the diacritic x00ef. To the eye, the Unicode CN can be easily be mistaken for a FQDN because of the small difference between the character with the diacritic x00ef and the ASCII i x0069. The Exchange certificate task doesn't require or enforce that the subject CN be a valid FQDN. By default, this means that the cmdlet includes the FQDN of the server as the default CN.

Certificate Domain Names

For TLS, certificates must contain DNS names because the TLS relies on DNS resolution. Clients verify the DNS name of the server to which they are connecting with the DNS name that they expect to be connecting to. This is true for Web browsers that connect to a Web site over HTTPS and for SMTP servers that transmit e-mail over the Internet or intranet. A single server may support multiple DNS names for the following reasons:

A SMTP server supports multiple accepted domains A client can access an e-mail server by the server name, by the domain name, by a FQDN local name, or by a load-balanced name. When a TLS connection is established, if the client finds the name that it is looking for, the client ignores the other names in the certificate. Multiple domain and server names can be added to the Subject Alternative Name field of a TLS certificate. You can create a certificate that contains multiple Subject Alternative Names by using the DomainName parameter of the New-ExchangeCertificate cmdlet. The DomainName parameter is multivalued so that it can accept multiple names. X.509 certificates can contain zero, one, or more DNS names in the Subject Alternative Name (SubjectAltName) certificate extension. DNS names in the SubjectAltName extension exactly match the restrictions of a DNS name. They must not exceed 255 characters and must consist of A-Z, a-z, 0-9 and a dash (-).

Name Matching Logic for the Domain Security Feature

The certificate name matching logic for the Domain Security feature checks whether a domain name in the received certificate matches the domain name when it sends mail to that domain. For example, consider the FQDN of the recipient domain woodgrovebank.com. The certificate name matching logic searches through all DNS names in the certificates, and as long as one DNS name matches, the certificate is verified as a match for the specified domain. In this example, the certificate name matching logic accepts a certificate with an exact domain match, such as woodgrovebank.com. It also supports using wildcard character domain names in certificates so that a certificate with a DNS name of *.woodgrovebank.com is accepted as a match. For more information about wildcard character domain names, see "Wildcard Character Domain Names" later in this topic. The certificate name matching logic also searches DNS one node deep. Therefore, mail1.woodgrovebank.com is also accepted as a match for woodgrovebank.com. However, DNS names more than two nodes deep aren't accepted. Therefore, mail1.us.woodgrovebank.com, for example, would not be accepted as a match for woodgrovebank.com.

Best Practices for Domain Names for Internet SMTP

When you create a certificate or a certificate request for an Edge Transport server performing SMTP TLS over the Internet, the set of domain names that you should include in the request are as follows:

The fully qualified Internet domain name of the server This may be different from the internal FQDN that is used between Edge Transport servers and Hub Transport servers and should match the A record that is published on the Internet (public) DNS server. This name should be entered as a CN in the SubjectName parameter of the New-ExchangeCertificate cmdlet. All the accepted domain names of the organization Use the IncludeAcceptedDomains parameter of the New-ExchangeCertificate cmdlet to populate the Subject Alternative Name for the resulting certificate. The FQDN for the connector if it isn't covered by either of the previous items Use the DomainName parameter of the New-ExchangeCertificate cmdlet to populate the Subject Alternative Name for the resulting certificate.

Wildcard Character Domain Names

Wildcard character domain names are a special type of domain name that represents multiple sub-domains. Wildcard character domain names can simplify certificates because a single wildcard domain name represents all the sub-domains for that domain. They are represented by an asterisk character ( * ) at the DNS node. For example, *.contoso.com represents contoso.com and all the sub-domains for contoso.com. When you use a wildcard character to create a certificate or a certificate request for all accepted domains, you can simplify the request significantly.

Certificate Selection
Exchange follows different certificate selection processes depending on the type of SMTP connection. When Hub Transport servers are communicating with each other or with the Edge Transport servers in your organization, anonymous TLS certificates are used. For more information, see Selection of Inbound Anonymous TLS Certificates and Selection of Outbound Anonymous TLS Certificates. When an SMTP host or client connects to the Edge or Hub Transport servers, then the STARTTLS certificate selection process is used. For more information, see Selection of Inbound STARTTLS Certificates.

Creating TLS Certificates

Exchange 2010 creates a self-signed certificate during installation that uses all the server and domain names that are known to Exchange at the time of installation. You can clone this certificate to use it on additional servers. You can also replace this certificate with certificates that are issued by a third-party CA. The following topics provide step-by-step instructions for each task.

Generate Request for Third-Party Certificate Services Install Certificates Issued for Certificate Requests Clone an Existing Certificate

References
For more information about cryptography and certificate technologies and concepts, see the following publications:

Windows Server 2008 PKI and Certificate Security Housley, Russ and Tim Polk. Planning for PKI: Best Practices Guide for Deploying Public Key Infrastructure. New York: John Wiley & Son, Inc., 2001. Schneier, Bruce. Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2nd Edition. New York: John Wiley & Son, Inc., 1996.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

TLS Functionality and Related Terminology in Exchange 2010

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-11-25 Microsoft Exchange Server 2010 provides administrative functionality and other enhancements that improve the overall management of Transport Layer Security (TLS). As you work with this functionality, you need to learn about some TLS-related features and functionality. Some terms and concepts apply to more than one TLS-related feature. In this topic, a brief explanation of each feature is provided, which is intended to help you understand some differences and general terminology related to TLS and the Domain Security feature set:

Transport Layer Security TLS is a standard protocol that's used to provide secure Web communications on the Internet or intranets. It enables clients to authenticate servers or, optionally, servers to authenticate clients. It also provides a secure channel by encrypting communications. TLS is the latest version of the Secure Sockets Layer (SSL) protocol. Mutual TLS Mutual TLS authentication differs from TLS as TLS is usually deployed. Typically, when TLS is deployed, it's used only to provide confidentiality in the form of encryption. No authentication occurs between the sender and receiver. In addition to this kind of deployment, sometimes when TLS is deployed, only the receiving server is authenticated. This deployment of TLS is typical of the HTTP implementation of TLS. This implementation, where only the receiving server is authenticated, is SSL. With mutual TLS authentication, each server verifies the identity of the other server by validating a certificate that's provided by that other server. In this scenario, where messages are received from external domains over verified connections in an Exchange 2010 environment, Microsoft Outlook displays a Domain Secured icon. Domain Security Domain Security is the set of features, such as certificate management, connector functionality, and Outlook client behavior that enables mutual TLS as a manageable and useful technology. Opportunistic TLS In earlier versions of Exchange, you had to configure TLS manually. In addition, you had to install a valid certificate, suitable for TLS usage, on the server running Exchange. In Exchange 2010, Setup creates a self-signed certificate. By default, TLS is enabled. This enables any sending system to encrypt the inbound SMTP session to Exchange. By default, Exchange 2010 also attempts TLS for all remote connections. Direct trust By default, all traffic between Edge Transport servers and Hub Transport servers is authenticated and encrypted. Again, the underlying mechanism for authentication and encryption is mutual TLS. Instead of using X.509 validation, Exchange 2010 uses direct trust to authenticate the certificates. Direct trust means that the presence of the certificate in Active Directory or Active Directory Lightweight Directory Services (AD LDS) validates the certificate. Active Directory is considered a trusted storage mechanism. When direct trust is used, it doesn't matter if the certificate is self-signed or signed by a certification authority. When you subscribe an Edge Transport server to the Exchange organization, the Edge Subscription publishes the Edge Transport server certificate in Active Directory for the Hub Transport servers to validate. The Microsoft Exchange EdgeSync service updates AD LDS with the set of Hub Transport server certificates for the Edge Transport server to validate. 2010 Microsoft Corporation. All rights reserved.
2013 Microsoft. All rights reserved.

Selection of Inbound Anonymous TLS Certificates

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-11-23 The selection of an inbound anonymous Transport Layer Security (TLS) certificate occurs in the following scenarios:

SMTP sessions between Edge Transport servers and Hub Transport servers for authentication SMTP sessions between Hub Transport servers for encryption only by using public keys For communication between Hub Transport servers, anonymous TLS and the public keys from certificates are used to encrypt the session. Kerberos is used for authentication. When an SMTP session is established, the receiving server initiates a certificate selection process to determine which certificate to use in the TLS negotiation. The sending server also performs a certificate selection process. For more information about that process, see Selection of Outbound Anonymous TLS Certificates. This topic describes the selection process for inbound anonymous TLS certificates. All the steps are performed on the receiving server. The following figure shows the steps of this process.

1. When the SMTP session is established, Microsoft Exchange calls a process to load the certificates. 2. In the load certificate function, the Receive connector to which the session is connected is checked to see whether the AuthMechanism property is set to a value of ExchangeServer. You can set the AuthMechanism property on the Receive connector by using the Set-ReceiveConnector cmdlet. You can also set the AuthMechanism property to ExchangeServer by selecting Exchange Server authentication on the Authentication tab of a specific Receive connector. If ExchangeServer isn't enabled as an authentication mechanism, the server doesn't advertise X-ANONYMOUSTLS to the sending server in the SMTP session and no certificate is loaded. If ExchangeServer is enabled as an authentication mechanism, the certificate selection process continues to the next step. 3. Microsoft Exchange queries Active Directory to retrieve the thumbprint of the certificate on the server. The msExchServerInternalTLSCert attribute on the server object stores the certificate thumbprint. If the msExchServerInternalTLSCert attribute can't be read or if the value is null, Microsoft Exchange doesn't advertise X-ANONYMOUSTLS and no certificate is loaded. Note: If the msExchServerInternalTLSCert attribute can't be read or if the value is null during startup of the Microsoft Exchange Transport service, instead of during the SMTP session, Event ID 12012 is logged in the Application log. 4. If a thumbprint is found, the certificate selection process searches the local computer certificate store for a certificate that matches the thumbprint. If the certificate isn't found, the server doesn't advertise X-ANONYMOUSTLS, no certificate is loaded, and Event ID 12013 is logged in the Application log. 5. After a certificate is loaded from the certificate store, it's checked to see whether it has expired. The Valid to field on the certificate is compared to the current date and time. If the certificate has expired, Event ID 12015 is logged in the Application log. In this case, the certificate selection process doesn't fail and continues with the remaining checks. 6. The certificate is checked to see whether it's the latest in the local computer's certificate store. As part of this check, a domain list is built for potential certificate

domains. The domain list is based on the following computer configuration: Fully qualified domain name (FQDN), such as mail.contoso.com Host name, such as EdgeServer01 Physical FQDN, such as EdgeServer01.contoso.com Physical host name, such as EdgeServer01 Note: If the server is configured as a cluster or for a computer that's running Microsoft Windows Load Balancing, the following registry key is checked instead of the DnsFullyQualifiedDomainName setting: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WLBS\Parameters\Interface\{GUID}\ClusterName 7. After the domain list is built, the certificate selection process checks to find all certificates in the certificate store that have a matching FQDN. From this list, the certificate selection process identifies a list of eligible certificates. Eligible certificates must meet the following criteria: The certificate is an X.509 version 3 or a later version certificate. The certificate has an associated private key. The Subject or Subject Alternate Name fields contain the FQDN that was retrieved in step 6. The certificate is enabled for Secure Sockets Layer (SSL)/TLS use. Specifically, the SMTP service has been enabled for this certificate by using the EnableExchangeCertificate cmdlet. 8. From the eligible certificates, the best certificate is selected based on the following sequence: a. Sort eligible certificates by most recent Valid from date. Valid from is a Version 1 field on the certificate. b. The first valid public key infrastructure (PKI) certificate that's found in this list is used. c. If no valid PKI certificates are found, the first self-signed certificate is used. 9. After the best certificate has been determined, another check is made to determine whether its thumbprint matches the certificate that's stored in the msExchServerInternalTLSCert attribute. If the certificate matches, the certificate is used for X-ANONYMOUSTLS. If it doesn't match, Event ID 1037 is logged in the Application log. However, this doesn't cause X-ANONYMOUSTLS to fail. 2010 Microsoft Corporation. All rights reserved.
2013 Microsoft. All rights reserved.

Selection of Inbound STARTTLS Certificates

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-04-27 The selection of an inbound STARTTLS certificate occurs in the following scenarios:

SMTP hosts request Transport Layer Security (TLS) with Edge Transport servers. The host that requests TLS with the Edge Transport server may be any other SMTP host. This also describes the Domain Security scenario. For more information about Domain Security, see Understanding Domain Security. SMTP clients, such as Microsoft Outlook Express, request TLS with Hub Transport servers. Internet-facing Hub Transport servers request TLS with an Edge Transport server. When an SMTP session is established, the receiving server initiates a certificate selection process to determine which certificate to use in the TLS negotiation. The sending server also performs a certificate selection process. For more information about that process, see Selection of Outbound Anonymous TLS Certificates. This topic describes the certificate selection process for inbound STARTTLS. All the steps described in this topic are performed on the receiving server. The following figure shows the steps of this process.

1. When the SMTP session is established, Microsoft Exchange calls a process to load the certificates. 2. In the load certificate function, the Receive connector to which the session is connected is checked to see whether the AuthMechanism property is set to a value of TLS. You can set the AuthMechanism property on the Receive connector by using the Set-ReceiveConnector cmdlet. You can also set the AuthMechanism property to TLS by selecting Transport Security Layer (TLS) on the Authentication tab of a specific Receive connector. If TLS isn't enabled as an authentication mechanism, the server doesn't advertise X-STARTTLS as an option to the sending server and no certificate is loaded. If TLS is enabled as an authentication mechanism, the certificate selection process continues to the next step. 3. The certificate selection process retrieves the fully qualified domain name (FQDN) value from the Receive connector configuration. If the FQDN value on the Receive connector is null, the server's physical FQDN is retrieved. 4. The certificate selection process searches the local computer certificate store for certificates that match the FQDN. If a certificate isn't found, the server doesn't advertise X-STARTTLS, no certificate is loaded, and Event ID 12014 is logged in the Application log. 5. The certificate selection process searches for all certificates in the certificate store that have a matching FQDN. From this list, the certificate selection process identifies a list of eligible certificates. Eligible certificates must meet the following criteria: The certificate is an X.509 version 3 or a later version certificate. The certificate has an associated private key. The Subject or Subject Alternate Name fields contain the FQDN that was retrieved in step 3. The certificate is enabled for SSL/TLS use. Specifically, the SMTP service has been enabled for this certificate by using the Enable-ExchangeCertificate cmdlet. 6. If no eligible certificates are found after these checks, the server doesn't advertise X-STARTTLS, no certificate is loaded, and Event ID 12014 is logged in the Application log. 7. From the eligible certificates, the best certificate is selected based on the following sequence: a. Sort eligible certificates by most recent Valid from date. Valid from is a Version 1 field on the certificate. b. The first valid public key infrastructure (PKI) certificate that's found in this list is used. c. If no valid PKI certificates are found, the first self-signed certificate is used. 8. The certificate is checked to see whether it has expired. The Valid to field in the certificate properties is compared to the current date and time. If the certificate hasn't expired, STARTTLS is advertised. If the certificate has expired, Event ID 12016 is logged in the Application log, but STARTTLS is still advertised. 2010 Microsoft Corporation. All rights reserved.
2013 Microsoft. All rights reserved.

Selection of Outbound Anonymous TLS Certificates

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-12-07 This topic describes the selection process for outbound anonymous Transport Layer Security (TLS) certificates in Microsoft Exchange Server 2010. The selection of an outbound anonymous TLS certificate occurs in the following scenarios:

SMTP sessions between Edge Transport servers and Hub Transport servers for authentication SMTP sessions between Hub Transport servers for encryption only by using public keys For communication between Hub Transport servers, anonymous TLS and the public keys from certificates are used to encrypt the session. When an SMTP session is established, the receiving server initiates a certificate selection process to determine which certificate to use in the TLS negotiation. The receiving server also performs a certificate selection process. For more information about that process, see Selection of Inbound Anonymous TLS Certificates.

Sending from a Hub Transport Server or an Edge Transport Server

All the steps for the selection of an outbound anonymous TLS certificate are performed on the sending server. The following figure shows the steps of this process.

1. When the SMTP session is established from a Hub Transport server or Edge Transport server, Microsoft Exchange calls a process to load the certificates.

Note: During the initial loading of the certificate, the outbound certificate selection process is different for the Edge Transport server role and the Hub Transport server role. The figure shows the starting point for each server role. 2. The certificate loading process depends on whether the SMTP session is initiated from a Hub Transport server or an Edge Transport server. On a Hub Transport server The following checks are made: a. The Send connector to which the session is connected is checked to see whether the SmartHostAuthMechanism property is configured for ExchangeServer. You can set the SmartHostAuthMechanism property on the Send connector by using the Set-SendConnector cmdlet. You can also set the SmartHostAuthMechanism property to ExchangeServer by selecting Exchange Server Authentication on the Configure Smart Host Authentication Settings page of a specific Send connector. To open the Configure Smart Host Authentication Settings page, click Change on the Network tab of the Send connector properties page. b. The DeliveryType property of the message is checked to determine whether it's set to a value of SmtpRelayWithinAdSitetoEdge. You can view the DeliveryType property by running the Get-Queue cmdlet with the format list argument ( | Format-List). Both of the following conditions must be met. If ExchangeServer isn't enabled as an authentication mechanism or if the DeliveryType property isn't set to SmtpRelayWithinAdSitetoEdge, the sending Hub Transport server doesn't use anonymous TLS and no certificate is loaded. If both conditions are met, the certificate selection process continues to step 3. On an Edge Transport server The following checks are made: a. The Send connector to which the session is connected is checked to see whether the SmartHostAuthMechanism property is configured for ExchangeServer. As noted earlier in this topic, you can set the SmartHostAuthMechanism property on the Send connector by using the SetSendConnector cmdlet. You can also set the SmartHostAuthMechanism property to ExchangeServer by selecting Exchange Server Authentication on the Configure Smart Host Authentication Settings page of a specific Send connector. To open the Configure Smart Host Authentication Settings page, click Change on the Network tab of the Send connector properties page. b. The Send connector to which the session is connected is checked to determine whether the SmartHost address space property contains "- -". Both of the following conditions must be met. If ExchangeServer isn't enabled as an authentication mechanism or the address space doesn't contain - , the sending Edge Transport server doesn't use anonymous TLS and no certificate is loaded. If both conditions are met, the certificate selection process continues to step 3. 3. Microsoft Exchange queries Active Directory to retrieve the thumbprint of the certificate on the server. The msExchServerInternalTLSCert attribute on the server object stores the certificate thumbprint. If the msExchServerInternalTLSCert attribute can't be read or if the value is null, Microsoft Exchange doesn't advertise X-ANONYMOUSTLS in the SMTP session and no certificate is loaded. Note: If the msExchServerInternalTLSCert attribute can't be read or if the value is null during startup of the Microsoft Exchange Transport service, instead of during the SMTP session, Event ID 12012 is logged in the Application log. 4. If a thumbprint is found, the certificate selection process searches the local computer certificate store for a certificate that matches the thumbprint. If the certificate isn't found, the server doesn't advertise X-ANONYMOUSTLS, no certificate is loaded, and Event ID 12013 is logged in the Application log. 5. After a certificate is loaded from the certificate store, it's checked to see whether it has expired. The Valid to field on the certificate is compared to the current date and time. If the certificate has expired, Event ID 12015 is logged in the Application log. In this case, the certificate selection process doesn't fail and continues with the remaining checks. 6. The certificate is checked to see whether it's the latest in the local computer's certificate store. As part of this check, a domain list is built for potential certificate domains. The domain list is based on the following computer configuration: Fully qualified domain name (FQDN), such as mail.contoso.com Host name, such as EdgeServer01 Physical FQDN, such as EdgeServer01.contoso.com Physical host name, such as EdgeServer01 Note: If the server is running Microsoft Windows Load Balancing, the following registry key is checked instead of the DnsFullyQualifiedDomainName setting: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WLBS\Parameters\Interface\{GUID}\ClusterName 7. After the domain list is built, the certificate selection process performs a search to find all certificates in the certificate store that have a matching FQDN. From this list, the certificate selection process identifies a list of eligible certificates. Eligible certificates must meet the following criteria: The certificate is an X.509 version 3 or a later version certificate. The certificate has an associated private key. The Subject or Subject Alternate Name fields contain the FQDN that was retrieved in step 6. The certificate is enabled for Secure Sockets Layer (SSL)/TLS use. Specifically, the SMTP service has been enabled for this certificate by using the EnableExchangeCertificate cmdlet. 8. From the eligible certificates, the best certificate is selected based on the following sequence: a. Sort eligible certificates by most recent Valid from date. Valid from is a Version 1 field on the certificate. b. The first valid public key infrastructure (PKI) certificate that's found in this list is used. c. If no valid PKI certificates are found, the first self-signed certificate is used. 9. After the best certificate has been determined, another check is made to determine whether its thumbprint matches the certificate that's stored in the msExchServerInternalTLSCert attribute. If the certificate matches, the certificate is used for X-ANONYMOUSTLS. If it doesn't match, Event ID 1037 is logged in the Application log. However, this doesn't cause X-ANONYMOUSTLS to fail.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Disabling TLS Between Active Directory Sites to Support WAN Optimization

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-12-01 In Microsoft Exchange Server 2007, Transport Layer Security (TLS) encryption is mandatory for all SMTP communication between Hub Transport servers. This increases overall security of hub-to-hub communications. However, in certain topologies where WAN Optimization Controller (WOC) devices are used, the TLS encryption of SMTP traffic may be undesirable. Exchange Server 2010 supports disabling TLS for hub-to-hub communications for these specific scenarios. Consider the topology shown in the following figure. The assumption for this four-site topology is that the two central office sites and Branch Office 2 are well-connected, whereas the connection between Central Office Site 1 and Branch Office 1 is over a WAN link. The company has installed WOC devices on this link to compress and optimize traffic over the WAN.

In this topology, because Exchange 2010 uses TLS encryption for communication between Hub Transport servers, the SMTP traffic that goes over the WAN link can't be compressed. Ideally, all SMTP traffic that goes over the WAN link should be unencrypted SMTP, while retaining TLS security within well-connected sites. Exchange 2010 gives you the option to disable TLS encryption for traffic between sites by configuring Receive connectors. Using this ability in Exchange 2010, you can configure an exception to the SMTP traffic between Central Office Site 1 and Branch Office 1, as shown in the following figure.

The recommended configuration is to limit the non-encrypted SMTP traffic to only those messages that pass over the WAN link. Therefore, the intrasite hub-to-hub traffic in all sites, and the cross-site hub-to-hub communications that don't involve Branch Office 1 should all be TLS encrypted. To achieve this end result, you need to do the following, in the specified order, on every Hub Transport server in the sites that contain the WOC devices (Central Office Site 1 and Branch Office 1 in the sample topology):

1. 2. 3. 4.

Enable downgraded Exchange Server authentication. Create a Receive connector to handle the traffic over the connection that has WOC devices. Configure the remote IP address range property of the new Receive connector to the IP address ranges of the Hub Transport servers in the remote site. Disable TLS on the new Receive connector.

In addition, you need to do the following to ensure all SMTP traffic over the WAN is handled by the new Receive connectors you created:

Configure the sites that will participate in the non-TLS communication as hub sites to force all message flow through the new Receive connectors (Central Office Site 1 and Branch Office Site 1 in the sample topology). Verify that the IP site link costs are configured in a way that ensures the least cost routing path to your remote site (Branch Office 1 in the sample topology) goes through the network link that has the WOC devices. The following sections provide an overview of each of these steps. For step-by-step instructions on how to configure your Hub Transport servers to disable TLS, see Suppress Anonymous TLS Connections. Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents Downgrading Authentication over TLS-Disabled Connections Creating and Configuring Receive Connectors Creating Hub Sites Configuring Site Link Costs

Downgrading Authentication over TLS-Disabled Connections

Kerberos authentication is used with TLS encryption in Exchange. When you disable TLS on hub-to-hub communications, you need to perform another form of authentication. When Exchange 2010 communicates with other servers running Exchange that don't support X-ANONYMOUSTLS, such as the Exchange Server 2003 servers, it falls back to using GSSAPI (Generic Security Services Application Programming Interface) authentication. All communications between Exchange 2010 Hub

Transport servers use X-ANONYMOUSTLS. By configuring your Hub Transport server to use downgraded Exchange Server authentication, you are in effect enabling it to use GSSAPI when communicating with other Exchange 2010 Hub Transport servers. Return to top

Creating and Configuring Receive Connectors

You need to create Receive connectors that will solely be responsible for handling the non-TLS encrypted traffic. Using separate Receive connectors for this purpose ensures that all traffic that doesn't pass through the WAN link remains protected by TLS encryption. To restrict the new Receive connectors to only the traffic over the WAN, you need to configure the remote IP address range property. Exchange always uses the connector with the most specific remote IP address range. Therefore, these new connectors will be preferred over the default Receive connector configured to receive messages from anywhere. Going back to the sample topology, assume that the class C subnet 10.0.1.0/24 is used for the Central Office Site 1 and 10.0.2.0/24 is used for the Branch Office 1. To prepare for disabling TLS between these two sites, you need to:

1. 2. 3. 4.

Create a Receive connector (called WAN) on each Hub Transport server in Central Office Site 1 and Branch Office 1. Configure the remote IP address range of 10.0.2.0/24 on each new Receive connector in Central Office Site 1. Configure the remote IP address range of 10.0.1.0/24 on each new Receive connector in Branch Office 1. Disable TLS on all of the new Receive connectors.

The end result is shown in the following figure (with the remote IP address range property of the WAN Receive connectors shown in parentheses). Only a single Hub Transport server is shown in Branch Office 1, and Branch Office 2 is omitted for clarity purposes.

Return to top

Creating Hub Sites

By default, an Exchange 2010 Hub Transport server will attempt a direct connection to the Hub Transport server closest to the final destination of a specific message. In the sample topology, if a user in Branch Office 2 sends a message to a user in Branch Office 1, the Hub Transport server in Branch Office 2 will connect to the Hub Transport server in Branch Office 1 directly to deliver that message. That connection will be encrypted and therefore not desirable in the specific topology. To have such messages pass through the Hub Transport servers on Central Office Site 1, thereby ensuring they aren't encrypted while in transit over the WAN link, Central Office Site 1 and Branch Office 1 need to be configured as hub sites. In short, any site where you have a Hub Transport server with a Receive connector with TLS disabled needs to be configured as a hub site, so you can force servers in other sites to route traffic through that site. For more information about hub sites, see "Implementing Hub Sites" in Understanding Message Routing. Return to top

Configuring Site Link Costs

Configuring hub sites alone isn't sufficient to ensure that all traffic is unencrypted over the WAN link. This is because Exchange will route messages through hub sites only if the hub site lies within the least cost routing path. For example, assume that the IP site link costs for our sample topology are configured in Active Directory as shown in the following figure (Central Office Site 2 is omitted for clarity).

In this case, the path from Branch Office 2 to Branch Office 1 that goes through the hub site has a total cost of 12 (6+6), whereas the cost of the direct path is 10. Therefore, none of the messages from Branch Office 2 to Branch Office 1 will go through Central Office Site 1 and therefore all of that traffic will still be TLS encrypted. To avoid this issue, you need to designate an Exchange-specific cost that is higher than 12 for the IP site link between Branch Office 2 and Branch Office 1, as shown in the following figure. This will ensure that all messages go through the unencrypted channel between Central Office Site 1 and Branch Office 1.

For more information about configuring Exchange-specific IP site link costs, see "Controlling IP Site Link Costs" in Understanding Message Routing. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Transport Agents

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-01-15 Transport agents let you install custom software, created by Microsoft, by third-party vendors, or by your organization, on a computer that is running Microsoft Exchange Server 2010. This software can then process e-mail messages that pass through the transport pipeline on a Hub Transport server or Edge Transport server. Custom transport agents provide additional functionality to Exchange 2010, such as anti-spam or antivirus programs or any transport function that your organization may require. Transport agents are typically installed automatically as part of applications that are designed to function together with Exchange 2010. However, there may be instances where organizations want to develop their own transport agents to manage mail that flows through their Exchange 2010 organization.

Caution: Transport agents have full access to all e-mail messages that they encounter. Exchange puts no restrictions on a transport agent's behavior. Transport agents that are unstable or contain security flaws may affect the stability and security of Exchange. Therefore, you must only install transport agents that you fully trust and that have been fully tested in a test environment. Looking for management tasks related to managing transport agents? See Managing Transport Agents. Contents Transport Agents and SMTP Events Prioritization of Transport Agents Built-In Transport Agents Troubleshooting Transport Agents

Transport Agents and SMTP Events

Transport agents that are written for Exchange 2010 use SMTP events. These events are triggered as messages move through the transport pipeline. SMTP events give transport agents access to messages at specific points during the SMTP conversation and during routing of messages through the organization. The following tables list the SMTP events that provide access to messages in the transport pipeline.

SMTP Receive events

Sequence 1 2 3 4 5 6 7 8 9 10 ** SMTP event OnConnect OnEhloCommand OnHeloCommand OnAuthCommand OnEndOfAuthentication OnMailCommand OnRcptToCommand OnDataCommand OnEndOfHeaders OnEndOfData OnHelpCommand Description This event is triggered upon initial connection from a remote SMTP host. This event is triggered when the EHLO SMTP verb is issued by the remote SMTP host. This event is triggered when the HELO SMTP verb is issued by the remote SMTP host. This event is triggered when the AUTH SMTP verb is issued by the remote SMTP host. This event is triggered when the remote SMTP host has completed authentication. This event is triggered when the MAIL FROM SMTP verb is issued by the remote SMTP host. This event is triggered when the RCPT TO SMTP verb is issued by the remote SMTP host. This event is triggered when the DATA SMTP verb is issued by the remote SMTP host. This event is triggered when the remote SMTP host as completed submitting the e-mail message headers. This event is triggered when the remote SMTP host issues <CRLF>, which indicates the end of data. This event is triggered when the HELP SMTP verb is issued by the remote SMTP host. This event can occur at any time after the OnConnect SMTP event and before the OnDisconnect SMTP event. ** OnNoopCommand This event is triggered when the NOOP SMTP verb is issued by the remote SMTP host. This event can occur at any time after the OnConnect SMTP event and before the OnDisconnect SMTP event. ** OnReject This event is triggered when the receiving SMTP host issues a temporary or permanent delivery status notification (DSN) code to the sending SMTP host. This event can occur at any time after the OnConnect SMTP event and before the OnDisconnect SMTP event. This event is triggered when the RSET SMTP verb is issued by the sending SMTP host. This event can occur at any time

**

OnRsetCommand

after the OnConnect SMTP event and before the OnDisconnect SMTP event. 11 OnDisconnect This event is triggered upon disconnection of the SMTP conversation by either a receiving or sending SMTP host.

Categorizer events
Sequence 1 Categorizer event OnSubmittedMessage Description This event is triggered upon submission of a message into the Submission queues on the receiving SMTP host. All messages encounter this event whether they arrived via SMTP submission, MAPI submission, or the Pickup or Replay directories. This event is triggered after all the recipients have been resolved, but before the next hop has been determined for each recipient. The OnResolvedMessage routing event enables subsequent events to override the default routing behavior by using the per-recipient SetRoutingOverride method. This event is triggered after messages have been categorized, distribution lists have been expanded, and recipients have been resolved. This event is triggered when the Categorizer completes processing the message.

OnResolvedMessage

OnRoutedMessage

OnCategorizedMessage

Transport agents can be registered on any of the SMTP events that are listed in the preceding tables. However, the intended action of the transport agent usually dictates which SMTP events it will run on. Consider anti-spam agents as an example. For these agents, the most important consideration, other than the validity of the message contents, is the point at which a valid spam message is identified and rejected. The sooner a message that has been confirmed to be spam is rejected, the lower the cost to your organization. All the SMTP events that are triggered before the OnEndOfData SMTP event do not require that a non-delivery receipt (NDR) be generated by the receiving SMTP host. An NDR isn't generated because the full message contents aren't delivered before the OnEndOfData SMTP event is reached. Therefore, the sending SMTP host is still responsible for the final delivery of the message. If delivery to the receiving SMTP host fails before the OnEndOfData SMTP event, the sending SMTP host must generate the NDR to the message sender. After the OnEndOfData SMTP event is reached, the receiving SMTP host has accepted the full contents of the message. This means that the SMTP host now has the responsibility to successfully deliver the message and generate and send an NDR to the message sender. Therefore, it's critical that an anti-spam agent register itself on the SMTP events before the OnEndOfData SMTP event is reached to reduce the chance that the receiving SMTP host will store the message contents and have to generate an NDR to the message sender. However, for antivirus agents, the most important consideration is to make sure that every message is scanned. Agents that must see every message must be configured on the OnSubmittedMessage SMTP event. Every message that flows through the transport pipeline encounters the OnSubmittedMessage SMTP event because it occurs after all the possible submission entry points, such as SMTP submission from remote hosts, MAPI submission from computers that are running the Mailbox server role, the Pickup directory that is used by custom applications, or the Replay directory used by third-party e-mail applications. Return to top

Prioritization of Transport Agents

Exchange 2010 lets you specify the priority of transport agents that are included with Exchange and that are added by custom applications. If you specify the priority of a transport agent, you can control which agents act on a message first. Transport agents can be assigned a priority of 1 or higher. Transport agents with a priority closer to 1 are applied to messages first. However, the priority that you assign to a transport agent is only one factor that is used to determine the order in which transport agents are applied to messages. The second factor that is used to determine the priority of transport agents is where the SMTP event that has a registered transport agent fits within the sequence of SMTP events. As shown in the tables earlier in this topic, SMTP events have a specific sequence in which they are applied to messages that flow through the transport pipeline. Because transport agents are registered to specific SMTP events, the priority only comes into play for agents that are registered to the same SMTP event. For example, you may have transport agents configured as follows:

Transport agent AgentA with a priority of 1 registered to the OnEndofHeaders SMTP event Transport agent AgentB with a priority of 4 registered to the OnMailCommand SMTP event When you view the list of registered agents by using the Get-TransportAgent cmdlet, transport agent AgentA is listed with a higher priority than transport agent AgentB. However, when a message flows through the transport pipeline, transport agent AgentB will be applied to the message before transport agent AgentA because the OnMailCommand SMTP event encounters the message before the OnEndOfHeaders SMTP event. Return to top

Built-In Transport Agents

Exchange 2010 includes several default transport agents that enable it to provide features such as transport rules and journaling. By default, the transport agents listed in the following tables are installed on Hub Transport servers and Edge Transport servers. The following tables also provide links to topics that contain more information about each agent.

Hub Transport server transport agents

Agent Name Transport Rule agent RMS Decryption agent Priority 1 The priority of this agent isn't userconfigurable. SMTP events OnRoutedMessage OnSubmittedMessage Related topic Understanding Transport Rules Understanding Information Rights Management

Journal Report Decryption agent RMS Encryption agent

The priority of this agent isn't userconfigurable. The priority of this agent isn't userconfigurable. The priority of this agent isn't userconfigurable. The priority of this agent isn't userconfigurable.

OncCategorizedMessage

Understanding Journaling

OnRoutedMessage

Understanding Information Rights Management Understanding Information Rights Management Understanding Journaling

Prelicensing agent

OnRoutedMessage

Journaling agent

OnSubmittedMessage, OnRoutedMessage

Edge Transport server transport agents

Agent name Connection Filtering agent Priority 1 SMTP events OnConnectEvent, OnMailCommand, OnRcptComand, OnEndOfHeaders Related topic Understanding Connection Filtering Understanding Address Rewriting Understanding Transport Rules Understanding Content Filtering Understanding Sender ID Understanding Sender Filtering Understanding Recipient Filtering Understanding Protocol Logging

Address Rewriting Inbound agent Edge Rule agent Content Filter agent Sender ID agent Sender Filter agent Recipient Filter agent Protocol Analysis agent

2 3 4 5 6 7 8

OnRcptCommand, OnEndOfHeaders OnEndOfData OnEndOfData OnEndOfHeaders OnMailCommand, OnEndOfHeaders OnRcptCommand OnEndOfHeaders, OnEndOfData, OnReject, OnRsetCommand, OnDisconnectEvent OnEndOfData

Attachment Filtering agent

Understanding Attachment Filtering Understanding Address Rewriting

Address Rewriting Outbound agent Return to top

10

OnRcptCommand, OnEndOfHeaders

Troubleshooting Transport Agents

With transport agents, Exchange helps you control the flow of e-mail messages through your organization. This capability enables you to match your Exchange infrastructure to your organization's requirements instead of forcing your organization to match your e-mail infrastructure. As you customize your environment, the complexity of that environment increases. To help you troubleshoot issues that may occur and to help you verify that the changes that you make are applied to messages in the manner you expect, Exchange provides the following features:

Get-TransportPipeline cmdlet The Get-TransportPipeline cmdlet shows all the enabled transport agents, and the SMTP events on which they are registered, that have encountered messages in the transport pipeline between the time when the Microsoft Transport service was started and the time when the cmdlet was run. For more information, see View Transport Agents in the Transport Pipeline. Note: The information that is displayed by the Get-TransportPipeline cmdlet is generated only after a message has been sent through the transport pipeline. Also, only the transport agents that encountered the message are displayed. Pipeline Tracing Pipeline tracing enables you to create an exact snapshot of a whole message before and after it encounters each transport agent. Pipeline tracing enables you to determine which transport agent may have generated unexpected results or to verify that the transport agent behaves as expected.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Transport Database Configuration Options

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-10-26 Servers that have the Microsoft Exchange Server 2010 Hub Transport server role or the Edge Transport server role installed use Extensible Storage Engine (ESE) database technology for certain transport server components. Formerly known as JET, ESE is a method that defines a low-level API to the underlying database structures in Exchange 2010. ESE is used for the following transport components:

Message queue database A queue is a temporary holding location for messages waiting to enter the next stage of processing. Each queue represents a logical set of messages that a transport server processes in a specific order. For more information, see Understanding Transport Queues. IP filter database The IP filter database stores the IP Allow lists and IP Block lists that are part of connection filtering. For more information, see Understanding Connection Filtering. The message queue database and the IP filter database are separate ESE databases. These databases don't share any resources. However, you can configure ESE database configuration options on the Hub Transport server or Edge Transport server that apply to all the ESE databases that exist on the server.

Overview of ESE Databases

ESE databases use log files to accept, track, and maintain data. To enhance performance, all transactions are written first to log files and memory, and then to the database file. The checkpoint file tracks the transaction log entries that have been committed to the database. During an ordinary shutdown of the Microsoft Exchange Transport service, uncommitted database changes found in the transaction logs are always committed to the database. Circular logging is used for the message queue database and the IP filter database. This means that the history of committed transactions found in the transaction logs isn't maintained. Any transaction logs older than the current checkpoint are immediately and automatically deleted. Therefore, the transaction logs can't be replayed for message queue database recovery or IP filter database recovery from backup.

Understanding Storage Configuration

For best practice guidance about the storage configuration of ESE databases, see Understanding Storage Configuration.

Configuring Shared ESE Database Options on Transport Servers

The shared ESE database configuration options are available in the EdgeTransport.exe.config application configuration file located in the C:\Program Files\Microsoft\Exchange Server\V14\Bin directory. The EdgeTransport.exe.config file is an XML application configuration file associated with the EdgeTransport.exe file. EdgeTransport.exe and MSExchangeTransport.exe are the executable files used by the Microsoft Exchange Transport service. This service runs on every Hub Transport server or Edge Transport server. Changes saved to the EdgeTransport.exe.config file are applied after the Microsoft Exchange Transport service is restarted. If a configuration option is missing or is present and contains the default value, the default value is enforced. This example shows the typical structure of the EdgeTransport.exe.config file.

<configuration> <runtime> <gcServer enabled="true" /> </runtime> <appSettings> <add key="Configuration Option" value="Value" /> ... </appSettings> </configuration>

You can add new configuration options or modify existing configuration options in the <appSettings> section. Many configuration options are unrelated to the shared ESE database options. Any configuration options that don't involve the shared ESE database options are outside the scope of this topic. Note: The parameter names in the <add key=../> section are case sensitive. For information about the message queue database parameters available in the EdgeTransport.exe.config file, see Understanding Transport Queues. The following table shows the shared ESE database configuration options available in the EdgeTransport.exe.config file.

Shared ESE database configuration options

Parameter name DatabaseCacheFlushStart Description This parameter enables the removal of cached database transactions from memory when the cache is overused. The value of this parameter represents the percentage of the cache that's unused. When the free database cache resources drop under the specified percentage, a background process writes the cached database transactions to the transaction log. The default value is 3.

DatabaseCacheFlushStop

This parameter suspends the removal of cached database transactions from memory when the cache utilization level returns to normal. The value of this parameter represents the percentage of the cache that's unused. When the free database cache resources increase to more than the specified percentage, the background process that writes the cached database transactions to the transaction log is suspended. The default value is 5. This parameter controls the total allowed size of all uncommitted transaction logs that exist on the hard disk drive. The default value is 512MB. Setting the value of the DatabaseCheckPointDepthMax parameter too low can cause significant performance issues because uncommitted transactions are forcibly committed to the database instead of being written to transaction logs. We recommend that you don't modify the default value of the DatabaseCheckPointDepthMax parameter. This parameter specifies the maximum size of the database cache in memory. The default value is 1GB.

DatabaseCheckPointDepthMax

DatabaseMaxCacheSize

Remember that the message queue database and the IP filter database are isolated from one another. The ESE database files don't share database files, transaction logs, or caches. The shared configuration options apply to each database and its supporting infrastructure. For example, when you set the DatabaseMaxCacheSize parameter, you are also setting the maximum cache size for the message queue database and the IP filter database.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Transport Logs

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-11-09 Transport logs are generated by Hub Transport and Edge Transport servers and they provide information about the functioning of your transport pipeline. Transport servers can generate agent, connectivity, message tracking, protocol, and routing table logs. The following topics provide detailed information about each of these logs. Understanding Agent Logging Understanding Connectivity Logging Understanding Message Tracking Understanding Protocol Logging Understanding Routing Table Logging 2010 Microsoft Corporation. All rights reserved.
2013 Microsoft. All rights reserved.

Understanding Agent Logging

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-11-17 Agent logs record the actions performed on a message by specific anti-spam agents installed and configured on a computer running Microsoft Exchange Server 2010 that has the Edge Transport server role or the Hub Transport server role installed. Only the following agents can write information to the agent log:

Connection Filter agent Content Filter agent Edge Rules agent Recipient Filter agent Sender Filter agent Sender ID agent The information written to the agent log depends on the agent, the SMTP event, and the action performed on the message. The only configurable option for agent logging is the AgentLogEnabled parameter in the EdgeTransport.exe.config application configuration file. By default, agent logging is enabled on Hub Transport servers or Edge Transport servers. The other agent log values that aren't configurable are described in the following list:

Path where the agent logs are stored is C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\AgentLog. Maximum size for the individual agent log files is 10 megabytes (MB). Maximum size for the directory that contains the agent log files is 250 MB. Maximum age for the agent log files is 30 days. The Exchange 2010 server uses circular logging to limit the agent logs based on file size and file age to help control the hard disk space used by the log files. Note: If you want to keep the agent log files longer than allowed by file age or directory size values that you can't configure, you can create a scheduled task that periodically moves the unused agent log files to a different location. Note: By default, the transport logging process has a logging level value of 0 (Lowest). If you want Exchange to write an event log entry when circular logging removes a log file, you must change the logging level value of the transport logging process to 5 (Maximum) or 7 (Expert). Contents Overview of Transport Agents Structure of the Agent Log Files Information Written to the Agent Log Searching the Agent Logs Enable or Disable Agent Logging Looking for management tasks related to agent logging? See Managing Transport Servers.

Overview of Transport Agents

Agents can only act upon messages at specific points in the SMTP command sequence used to transport the messages through a Hub Transport server or Edge Transport server. These access points in the SMTP command sequence are called SMTP events. Each agent has a priority value that can be assigned. However, the SMTP events must always occur in a specific order. Therefore, the agent priority depends on the SMTP event. If two agents can act on a message during the same SMTP event, the agent that has the highest priority will act on the message first. The following table lists the SMTP events in order of occurrence and the agents that write information to the agent log in order of priority from highest to lowest for each SMTP event.

SMTP events in order of occurrence and the agents that write information to the agent log in order of priority for each SMTP event
SMTP event OnConnect OnMailCommand Agent Connection Filter agent Connection Filter agent Sender Filter agent Connection Filter agent Recipient Filter agent

OnRcptCommand

OnEndOfHeaders

Connection Filter agent Sender ID agent Sender Filter agent Edge Rules agent Content Filter agent

OnEndOfData

For more information about agents, SMTP events, and agent priority, see Understanding Transport Agents. Return to top

Structure of the Agent Log Files

The agent logs exist in C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\AgentLog. The naming convention for the agent log files is AGENTLOGyyyymmdd-nnnn.log. The placeholders represent the following information:

The placeholder yyyymmdd is the Coordinated Universal Time (UTC) date that the log file was created. The placeholder yyyy = year, mm = month, and dd = day. The placeholder nnnn is an instance number that starts at the value of 1 for each day. Information is written to the log file until the file size reaches 10 MB. Then, a new log file that has an incremented instance number is opened. This process is repeated throughout the day. Circular logging deletes the oldest log files when the agent log directory reaches 250 MB, or when a log file is 30 days old. The agent log files are text files that contain data in the comma-separated value file (CSV) format. Each agent log file has a header that contains the following information:

#Software Name of the software that created the agent log file. Typically, the value is Microsoft Exchange Server. #Version Version number of the software that created the agent log file. Currently, the value is 8.0.0.0. #Log-Type Log type value, which is Agent Log. #Date UTC date-time when the log file was created. The UTC date-time is represented in the ISO 8601 date-time format: yyyy-mm-ddThh:mm:ss.fffZ, where yyyy = year, mm = month, dd = day, hh = hour, mm = minute, ss = second, fff = fractions of a second, and Z signifies Zulu, which is another way to denote UTC. #Fields Comma delimited field names used in the agent log files. Return to top

Information Written to the Agent Log

The agent log stores each agent transaction on a single line in the log. The information stored on each line is organized by fields. These fields are separated by commas. The field name is generally descriptive enough to determine the type of information it contains. However, some of the fields may be blank. Or the type of information stored in the field may change based on the agent or the action performed on the message by the agent. The following table describes the fields used to classify each agent transaction.

Fields used to classify each agent transaction

Field name Timestamp Description UTC date-time of the agent event. This is represented in the ISO 8601 format. The value is formatted as yyyy-mm-ddThh:mm:ss.fffZ, where yyyy = year, mm = month, dd = day, hh = hour, mm = minute, ss = second, fff = fractions of a second, and Z signifies Zulu, which is another way to denote UTC. Unique SMTP session identifier. This identifier is represented as a 16-digit hexadecimal number. Local IP address and port number that accepted the message. SMTP sessions typically use port 25. IP address and port number of the previous SMTP server that connected to this server to deliver the message. In an Edge Transport server and Hub Transport server topology, the value of RemoteEndpoint in the agent log on the Hub Transport server will be the IP address of the Edge Transport server. Even though the message is transmitted by SMTP, the port number used by the sending server will be a random number larger than 1,024. IP address of the remote SMTP server that first connected to the Exchange organization to deliver the message. On an Edge Transport server, the value of RemoteEndpoint and EnteredOrgFromIP are the same. Anti-spam agents use the IP address in EnteredOrgFromIP to examine a message. Value of the MessageID header field. If this value is blank, the Exchange 2010 transport server assigns an arbitrary value, but only if the message is accepted. After assigned, the value of MessageID is constant for the lifetime of the message. P1FromAddress Sender e-mail address specified in MAIL FROM in the message envelope. This value is used to transport the message between SMTP messaging servers. This value serves as a comparison to the value of P2FromAddresses to determine whether the sender address in the message header is forged. P2FromAddresses Recipient Sender e-mail address specified in the From header field or in the Sender header field in the message header. E-mail address of the recipients. Although the original message may contain multiple recipients, only one recipient is displayed per line in the agent log. Total number of recipients in the original message.

SessionId LocalEndpoint RemoteEndpoint

EnteredOrgFromIP

MessageId

NumRecipients

Agent

Name of the agent that took the action. The possible values are as follows: Connection Filter agent Content Filter agent Edge Rules agent Recipient Filter agent Sender Filter agent Sender ID agent

Event

SMTP event where the action was taken by the agent. The value of Event depends on the agent. The SMTP events available to each agent are described in the first table earlier in this topic. The possible values for Event are as follows: OnConnect OnEndOfHeaders OnEndOfData OnMailCommand OnRcptCommand

Action

Action performed on the message by the agent. The possible values for Action are as follows: AcceptMessage DeleteMessage DeleteRecipients Disconnect QuarantineMessage QuarantineRecipients RejectAuthentication RejectCommand RejectConnection RejectMessage RejectRecipients

SmtpResponse Reason ReasonData Return to top

Enhanced SMTP response as defined in RFC 2034. Reason for the action supplied by the agent. Descriptive details for the action supplied by the agent.

Searching the Agent Logs

You can use the Get-AgentLog cmdlet in the Exchange Management Shell and the Get-AntiSpamFilteringReport script to search the agent logs. For more information, see Get-AgentLog. Return to top

Enable or Disable Agent Logging

By default, agent logging is enabled on a Hub Transport server or an Edge Transport server. Agent logging is enabled or disabled by modifying the EdgeTransport.exe.config file located in C:\Program Files\Microsoft\Exchange Server\V14\Bin. For more information, see Understanding the EdgeTransport.exe.Config File. EdgeTransport.exe and MSExchangeTransport.exe are the executable files used by the Microsoft Exchange Transport service. Many available configuration options are unrelated to agent logging. Any configuration options that don't involve agent logging are outside the scope of this topic.

1. Open the following file by using Notepad: C:\Program Files\Microsoft\Exchange Server\V14\Bin\EdgeTransport.exe.config 2. Modify the following line in the <appSettings> section.

<add key="AgentLogEnabled" value="<TRUE | FALSE>" />

This example disables agent logging by modifying the AgentLogEnabled parameter.

<add key="AgentLogEnabled" value="FALSE" />

3. Save and close the EdgeTransport.exe.config file. 4. Restart the Microsoft Exchange Transport service. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Connectivity Logging

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-11-18 Connectivity logging records the connection activity of the outbound message delivery queues that exist on computers running Microsoft Exchange Server 2010 that have the Hub Transport server role or the Edge Transport server role installed. The connectivity log tracks the connection activity from the sending queue to the destination Mailbox server, smart host, or domain. It isn't intended to track the transmission of individual e-mail messages. The following list describes the type of information recorded in the connectivity log:

Source queue, which can be the remote delivery queue or mailbox delivery queue Destination Mailbox server, smart host, or domain Domain Name System (DNS) resolution information Detailed information about connection failures Number of messages and bytes transmitted You use the Set-TransportServer cmdlet in the Exchange Management Shell to perform all connectivity log configuration tasks. The following options are available for the connectivity logs on an Edge Transport server or Hub Transport server:

Enable or disable connectivity logging. The default is disabled. Specify the location of the connectivity log files. Specify a maximum size for the individual connectivity log files. The default size is 10 megabytes (MB). Specify a maximum size for the directory that contains connectivity log files. The default size is 250 MB. Specify a maximum age for the connectivity log files. The default age is 30 days. By default, the Exchange 2010 server uses circular logging to limit the connectivity logs based on file size and file age to help control the hard disk space used by the connectivity log files. Looking for management tasks related to connectivity logging? See Managing Transport Servers.

Structure of the Connectivity Log Files

By default, the connectivity log files exist in C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\Connectivity. The naming convention for the connectivity log files is CONNECTLOGyyymmdd-nnnn.log. The placeholders represent the following information:

The placeholder yyyymmdd is the Coordinated Universal Time (UTC) date that the log file was created. The placeholder yyyy = year, mm = month, and dd = day. The placeholder nnnn is an instance number that starts at the value of 1 for each day. Information is written to the log file until the file size reaches its maximum specified value, and a new log file that has an incremented instance number is opened. This process is repeated throughout the day. Circular logging deletes the oldest log files when the connectivity log directory reaches its maximum specified size, or when a log file reaches its maximum specified age. The connectivity log files are text files that contain data in the comma-separated value file (CSV) format. Each connectivity log file has a header that contains the following information:

#Software Name of the software that created the connectivity log file. Typically, the value is Microsoft Exchange Server. #Version Version number of the software that created the connectivity log file. Currently, the value is 8.0.0.0. #Log-Type Log type value, which is Transport Connectivity Log. #Date UTC date-time when the log file was created. The UTC date-time is represented in the ISO 8601 date-time format: yyyy-mm-ddThh:mm:ss.fffZ, where yyyy = year, mm = month, dd = day, hh = hour, mm = minute, ss = second, fff = fractions of a second, and Z signifies Zulu, which is another way to denote UTC. #Fields Comma delimited field names used in the connectivity log files.

Information Written to the Connectivity Log

The connectivity log stores each outbound queue connection event on a single line in the connectivity log. The information stored on each line is organized by fields. These fields are separated by commas. The following table describes the fields used to classify each outgoing queue event.

Fields used to classify each connection event

Field name date-time Description UTC date-time of the connection event, which is represented in the ISO 8601 format. The value is formatted as yyyy-mm-ddThh:mm:ss.fffZ, where yyyy = year, mm = month, dd = day, hh = hour, mm = minute, ss = second, fff = fractions of a second, and Z signifies Zulu, which is another way to denote UTC. GUID that's unique for each SMTP session but is the same for each event associated with that SMTP session. For MAPI sessions, the session field is blank. Value of SMTP for connections from the remote delivery queue, or the value of MAPI for connections from the mailbox delivery queue. Name of the destination Mailbox server, smart host, or domain.

session

source Destination

direction

Single character that represents the start, middle, or end of the connection. The possible values for the direction field are as follows: + Connect - Disconnect > Send

description

Text information associated with the connection event. The following values are examples of values for the description field: Number and size of messages that were transmitted DNS MX resource record resolution information for destination domains DNS resolution information for destination Mailbox servers Connection establishment messages Connection failure messages

When an outbound delivery queue establishes a connection to a destination Mailbox server, smart host, or domain, the queue may be prepared to send one message or several messages. The connection and message transmission processes generate multiple events written on multiple lines in the connectivity log. Simultaneous connections to different destinations create connectivity log entries related to different destinations that are interlaced. However, you can use the date-time, session, source, and direction fields to arrange the connectivity log entries for each separate connection from start to finish.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Message Tracking

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-07-01 A message tracking log is a detailed log of all message activity as messages are transferred to and from a computer that is running Microsoft Exchange Server 2010 and that has the Hub Transport server role, the Mailbox server role, or the Edge Transport server role installed. Exchange servers that have the Client Access server role or Unified Messaging server role installed don't have message tracking logs. You use message tracking logs for message forensics, mail flow analysis, reporting, and troubleshooting. You can use the Set-TransportServer cmdlet for all message tracking configuration tasks on a Hub Transport server or Edge Transport server. You can use the SetMailboxServer cmdlet for all message tracking configuration tasks on a Mailbox server. For servers that have the Hub Transport server role and the Mailbox server role installed, you can use the Set-TransportServer cmdlet or the Set-MailboxServer cmdlet. You can use these cmdlets to make the following message tracking configuration changes:

Enable or disable message tracking: The default is enabled. Specify the location of the message tracking log files Specify a maximum size for the individual message tracking log files: The default is 10 MB. Specify a maximum size for the directory that contains the message tracking log files: The default is 1000 MB. Specify maximum age for the message tracking log files: The default is 30 days. Enable or disable message subject logging in the message tracking logs The default is enabled. Note: You can also use the Exchange Management Console on a Hub Transport server or Edge Transport server to enable or disable message tracking, and to specify the location of the message tracking log files. Exchange 2010 uses log rotation to limit the message tracking logs based on both file size and age. This helps limit the hard disk space that is used by the log files.

Structure of the Message Tracking Log Files

By default, the message tracking log files exist in C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\MessageTracking. The naming convention for log files in the message tracking log directory depends on the server role that is installed. On a Hub Transport server or an Edge Transport server, the log files are named MSGTRKyyyymmdd-nnnn.log. On a Mailbox server, the log files are named MSGTRKMyyyymmdd-nnnn.log. When the Hub Transport server role and Mailbox server role are installed on the same server, separate log files that use these different name prefixes are created in the message tracking log directory. The placeholders in the log file names represent the following information:

The placeholder yyyymmdd is the coordinated universal time (UTC) date on which the log file was created. yyyy = year, mm = month, and dd = day. The placeholder nnnn is an instance number that starts at the value of 1 daily for each message tracking log file name prefix. Information is written to each log file until the file size reaches its maximum specified value for each log file. Then, a new log file that has an incremented instance number is opened. This process is repeated throughout the day. The log file rotation functionality deletes the oldest log files when either of the following conditions is true:

A log file reaches its maximum specified age. The message tracking log directory reaches its maximum specified size. Important: The maximum size of the message tracking log directory is calculated as the total size of all log files that have the same name prefix. Other files that do not follow the name prefix convention are not counted in the total directory size calculation. Renaming old log files or copying other files into the message tracking log directory could cause the directory to exceed its specified maximum size. When the Hub Transport server role and the Mailbox server role are installed on the same server, the maximum size of the message tracking log directory is not the specified maximum size, because the message tracking log files that are generated by the different server roles have different name prefixes. When the Hub Transport server role and the Mailbox server role are installed on the same server, the maximum size of the message tracking log directory is two times the specified value. The message tracking log files are text files that contain data in the comma-separated value (CSV) format. Each message tracking log file has a header that contains the following information:

#Software: The name of the software that created the message tracking log file. Typically, the value is Microsoft Exchange Server. #Version: The version number of the software that created the message tracking log file. Currently, the value is 14.0.0.0. #Log-Type: The value of this field is Message Tracking Log. #Date: The UTC date-time when the log file was created. The UTC date-time is represented in the ISO 8601 date-time format: yyyy-mm-ddThh:mm:ss.fffZ, where yyyy = year, mm = month, dd = day, hh = hour, mm = minute, ss = second, fff = fractions of a second, and Z signifies Zulu, which is another way to denote UTC. #Fields: The comma-delimited field names that are used in the message tracking log files. The following fields are listed:

Information that is Written to the Message Tracking Log

The message tracking log stores each message event on a single line in the log. The events types that are used to classify each message event are explained in Table 1.

Table 1 Event Types that are Used to Classify Each Message Event

Event name BADMAIL DELIVER DEFER DSN DUPLICATEDELIVER

Description A message was submitted by the Pickup directory or the Replay directory that cannot be delivered or returned. A message was delivered to a mailbox. Message delivery was delayed. A delivery status notification (DSN) was generated. A duplicate message was delivered to the recipient. Duplication may occur if a recipient is a member of two distribution groups. Duplicate messages are detected and removed by the information store. A distribution group was expanded. Message delivery failed. A message is put in the poison message queue or removed from the poison message queue. A message was received and committed to the database. The RECEIVE event can be SMTP receive (Source: SMTP) or mail submitted by STOREDRIVER (Source: STOREDRIVER). SMTP RECEIVE can be from any source that submits a message by using SMTP. For example, it can be a Hub Transport server role, an Edge Transport server role, a third-party message transfer agent (MTA), or a POP/IMAP client. STOREDRIVER RECEIVE is logged by the EdgeTransport.exe process, and is the event that corresponds to a STOREDRIVER SUBMIT event. STOREDRIVER SUBMIT is logged by the Mail Submission process. These events can be on the same server if both server roles are installed locally, or they can be on different servers. Note: EdgeTransport.exe and MSExchangeTransport.exe are the executable files that are used by the Microsoft Exchange Transport service. This service runs on every Hub Transport server or Edge Transport server.

EXPAND FAIL POISONMESSAGE RECEIVE

REDIRECT RESOLVE SEND SUBMIT

A message was redirected to an alternative recipient after an Active Directory directory service lookup. A message's recipients were resolved to a different e-mail address after an Active Directory lookup. A message was sent by Simple Mail Transfer Protocol (SMTP) to a different server. A SUBMIT event is logged by the Mail Submission service on an Exchange 2007 computer that is running the Mailbox server role. The SUBMIT event is logged when the service has successfully notified a Hub Transport server that a message is awaiting submission in the mailbox store. The SourceContext property provides the Messaging Database (MDB) GUID, Mailbox GUID, Event sequence number, Message class, Creation time stamp of the client submission to store, and Client type. The Client type can be User (Outlook direct MAPI), RPCHTTP (Outlook Anywhere), Outlook Web Access, Exchange Web Services (EWS), Exchange ActiveSync, Assistants, or Transport. The message tracking logs that are generated by the Mailbox server role contain only SUBMIT events. Recipients were moved to a forked message because of content conversion, message recipient limits, or agents.

TRANSFER

The message event information that is stored on each line is organized by fields. These fields are separated by commas. The field name is generally descriptive enough to determine the type of information that it contains. However, some fields may be blank, or the type of information that is stored in the field may change based on the message event type as described in Table 1. General descriptions of the fields that are used to classify each message tracking event are explained in Table 2.

Table 2 Fields that are Used to Classify Each Message Tracking Event
Field name date-time Description

The UTC date-time of the message tracking event, which is represented in the ISO 8601 format. The value is formatted as yyyy-mm-ddThh:mm:ss.fffZ, where yyyy = year, mm = month, dd = day, hh = hour, mm = minute, ss = second, fff = fractions of a second, and Z signifies Zulu, which is another way to denote UTC. The TCP/IP address of the messaging server or messaging client that submitted the message. The name of the messaging server or messaging client that submitted the message.

client-ip clienthostname server-ip serverhostname sourcecontext connectorid source

The TCP/IP address of the source or destination Exchange server. The name of the destination server.

Extra information associated with the source field.

The name of source or destination Send connector or Receive connector.

The Exchange transport component responsible for the message tracking event. The possible values for this field are as follows: ADMIN for Replay directory submission AGENT

DSN GATEWAY for Foreign connector submission PICKUP ROUTING SMTP STOREDRIVER for MAPI submission

event-id

The message event type. These events are described fully in Table 1 earlier in this topic. The possible values are BADMAIL, DEFER, DELIVER, DSN, EXPAND, FAIL, POISONMESSAGE, RECEIVE, REDIRECT, RESOLVE, SEND, SUBMIT, and TRANSFER. A message identifier that is assigned by Exchange 2010 server that is currently processing the message. A specific message's value of internal-message-id is different in the message tracking log of every Exchange 2010 server that is involved in the delivery of the message. The value of the Message-Id: field found in the message's header fields. If the Message-Id: header field does not exist or is blank, an arbitrary value is assigned. This value is constant for the lifetime of the message. The e-mail addresses of the message's recipients. Multiple e-mail addresses are separated by the semicolon character (;).

internalmessageid messageid recipientaddress recipientstatus total-bytes recipientcount relatedrecipientaddress reference

This field is populated for a SEND event or a FAIL event.

The size of the message that includes attachments, in bytes. The number of recipients in the message.

This field is used with EXPAND, REDIRECT, and RESOLVE events to display other recipient e-mail addresses associated with the message.

This field contains additional information for specific types of events: DSN The Reference field contains the Internet-Message-Id of the message that caused the DSN. SEND The Reference field contains the Internet-Message-Id of any delivery status notification (DSN) messages. TRANSFER The Reference field contains the Internal-Message-Id of the message that is being forked. For all other types of events, the Reference field is blank. The message's subject found in the Subject: header field. The tracking of message subjects is controlled by the MessageTrackingLogSubjectLoggingEnabled parameter in the Set-TransportServer cmdlet for Hub Transport servers and Edge Transport servers, or in the Set-MailboxServer cmdlet for Mailbox servers. By default, message subject tracking is enabled. Message subject logging can be disabled by setting the value of the MessageTrackingLogSubjectLoggingEnabled parameter to $false. The e-mail address specified in the Sender: header field, or the From: header field if Sender: is not present.

messagesubject

senderaddress returnpath messageinfo

The return e-mail address specified by MAIL FROM: in the message envelope. Although this field is never empty, it can have the null sender address value represented as <>. This field contains the message origination date-time for DELIVER and SEND events. The origination date-time is the time that the message first enters the Exchange organization. The value is formatted as yyyy-mm-ddThh:mm:ss.fffZ, where yyyy = year, mm = month, dd = day, hh = hour, mm = minute, ss = second, fff = fractions of a second, and Z signifies Zulu, which is another way to denote UTC.

You can use the Get-MessageTrackingLog cmdlet in the Exchange Management Shell or the Message Tracking tool in the Exchange Management Console to search for messages by using specific message criteria.

Security Concerns for the Message Tracking Log

No message content is stored in the message tracking log. By default, the subject line of an e-mail message is stored in the message tracking log. You may want to disable message subject logging to comply with increased security or privacy requirements. Before you enable or disable message subject logging, make sure that you verify your organization's policy about revealing subject line information.

For More Information

For more information, see the following topics: Configure Message Tracking Search Message Tracking Logs

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Protocol Logging

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-11-23 Protocol logging records the SMTP conversations that occur between e-mail servers as part of message delivery. These SMTP conversations occur on Send connectors and Receive connectors configured on servers running Microsoft Exchange Server 2010 that have the Hub Transport server role or the Edge Transport server role installed. You can use protocol logging to diagnose mail flow problems. By default, protocol logging is disabled on all Send connectors and Receive connectors. Protocol logging is enabled or disabled on a per-connector basis. Other protocol logging options are set on a per-connector type basis for the whole server. All the Receive connectors on a Hub Transport server or an Edge Transport server share the same protocol log files and protocol log options. These protocol log files and protocol log options are separate from the Send connector protocol log files and protocol log options on the same server. The following options are available for the protocol logs of all Send connectors or all Receive connectors on an Edge Transport server or a Hub Transport server:

Specify the location of the Send connector or the Receive connector protocol log files. Specify a maximum size for the Send connector or the Receive connector protocol log files. The default size is 10 megabytes (MB). Specify a maximum size for the directory that contains the Send connector or Receive connector protocol log files. The default size is 250 MB. Specify a maximum age for the Send connector or Receive connector protocol log files. The default age is 30 days. By default, the Exchange 2010 server uses circular logging to limit the protocol logs based on file size and file age to help control the hard disk space used by the log files. A special Send connector named the intra-organization Send connector exists on every Hub Transport server. This connector is implicitly created, invisible, and requires no management. The intra-organization Send connector is used to relay messages to the following destinations:

To other Hub Transport servers in the Exchange organization, including Exchange 2007 Hub Transport servers To Exchange Server 2003 servers in the Exchange organization To Edge Transport servers in the Exchange organization By default, protocol logging for the intra-organization Send connector is disabled. You can enable or disable protocol logging for the intra-organization Send connector by using the IntraOrgConnectorProtocolLoggingLevel parameter on the Set-TransportServer cmdlet. If you enable protocol logging for the intra-organization Send connector, logging occurs in the Send connector protocol logs configured on the Hub Transport server. Looking for management tasks related to protocol logging? See Managing Transport Servers.

Structure of the Protocol Log Files

By default, the protocol log files exist in the following locations:

Receive connector protocol log files C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\ProtocolLog\SmtpReceive Send connector protocol log files C:\Program Files\Microsoft\Exchange Server\V14TransportRoles\Logs\ProtocolLog\SmtpSend The naming convention for log files in each protocol log directory is prefixyyyymmdd-nnnn.log. The placeholders represent the following information:

The placeholder prefix is SEND for Send connectors or RECV for Receive connectors. The placeholder yyyymmdd is the Coordinated Universal Time (UTC) date on which the log file was created. The placeholder yyyy = year, mm = month, and dd = day. The placeholder nnnn is an instance number that starts at the value of 1 for each day. Information is written to the log file until the file size reaches its maximum specified value, and a new log file that has an incremented instance number is opened. This process is repeated throughout the day. Circular logging deletes the oldest log files when the protocol log directory reaches its maximum specified size, or when a log file reaches its maximum specified age. The protocol log files are text files that contain data in the comma-separated value file (CSV) format. Each protocol log file has a header that contains the following information:

#Software Name of the software that created the protocol log file. Typically, the value is Microsoft Exchange Server. #Version Version number of the software that created the protocol log file. Currently, the value is 14.0.0.0. #Log-Type Log type value of this field, which is either SMTP Receive Protocol Log or SMTP Send Protocol Log. #Date UTC date-time when the log file was created. The UTC date-time is represented in the ISO 8601 date-time format: yyyy-mm-ddThh:mm:ss.fffZ, where yyyy = year, mm = month, dd = day, hh = hour, mm = minute, ss = second, fff = fractions of a second, and Z signifies Zulu, which is another way to denote UTC. #Fields Comma-delimited field names used in the protocol log files.

Information Written to the Protocol Log

The protocol log stores each SMTP protocol event on a single line in the protocol log. The information stored on each line is organized by fields. These fields are separated by commas. The following table describes the fields used to classify each protocol.

Fields used to classify each protocol event

Field name Description

date-time

UTC date-time of the protocol event, which is represented in the ISO 8601 format. The value is formatted as yyyy-mm-ddThh:mm:ss.fffZ, where yyyy = year, mm = month, dd = day, hh = hour, mm = minute, ss = second, fff = fractions of a second, and Z signifies Zulu, which is another way to denote UTC. Distinguished name (DN) of the connector associated with the SMTP event.

connectorid session-id sequencenumber localendpoint remoteendpoint event

GUID that's unique for each SMTP session but is the same for each event associated with that SMTP session. Counter that starts at 0 and is incremented for each event in the same SMTP session.

Local endpoint of an SMTP session. This consists of an IP address and TCP port number formatted as <IP address>:<port>.

Remote endpoint of an SMTP session. This consists of an IP address and TCP port number formatted as <IP address>:<port>.

Single character that represents the protocol event. The possible values for the event are as follows: + > < * Connect Disconnect Send Receive Information

data context

Text information associated with the SMTP event. Additional contextual information that may be associated with the SMTP event.

A single SMTP conversation that represents the sending or receiving of a single e-mail message generates multiple SMTP events. These SMTP events cause multiple lines to be written to the protocol log. Multiple SMTP conversations that represent the sending or receiving of multiple e-mail messages can occur at the same time. This creates protocol log entries from different SMTP conversations that are interspersed. You can use the session-id and sequence-number fields to sort the protocol log entries by SMTP conversation.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Routing Table Logging

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-11-17 Routing table logging periodically records a snapshot of the routing table that's used by the computer that's running Microsoft Exchange Server 2010 that has the Hub Transport server role or Edge Transport server role installed. The routing table is used to route messages to their destinations. The routing table log is recorded in these cases:

After a fixed time interval. After the Microsoft Exchange Transport service is started. After a routing configuration change is detected. The routing table log can be used to help troubleshoot mail flow and routing issues. You can control the automatic routing table recalculation interval in the EdgeTransport.exe.config application configuration file. This value controls how frequently the routing table is automatically recalculated and how frequently the routing table is logged. However, regular routing table updates may cause the routing table to be recalculated and logged earlier than the specified automatic recalculation interval as explained later in this topic. You use the Set-TransportServer cmdlet to perform all other routing table log configuration tasks. The following options are available for the routing table logs on an Edge Transport server or Hub Transport server:

Specify the location of the routing table log files. Specify a maximum size for the directory that contains routing table log files. The default size is 50 megabytes (MB). Specify a maximum age for the routing table log files. The default age is seven days. By default, the Exchange 2010 server uses circular logging to limit the connectivity logs based on file size and file age to help control the hard disk space that's used by the log files. In Exchange 2010, you can use the Routing Log Viewer in the Exchange Management Console to view and search the routing table logs. For more information, see Using the Routing Log Viewer. Looking for management tasks related to managing transport servers? See Managing Transport Servers.

Structure of the Routing Table Log Files

By default, the routing table log files exist in C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\Routing. The naming convention for the routing table log files is RoutingConfig#1@UTCcreationdate-time.xml. For example, depending on your regional date-time format settings, the routing table log files may be named RoutingConfig#1@mm_dd_yyyy hh_mm_ss.xml. The placeholders represent the following information: yyyy = year, mm = month, dd = day, hh = hour, mm = minute and ss = second. The date-time is always represented in Coordinated Universal Time (UTC). The routing table log is a complete snapshot of the routing table that's stored in memory. The routing table is written to the routing table log when the following events occur:

A routing configuration change is detected. An example of a configuration change is adding or removing a Send connector in the Exchange organization or a Receive connector on the local server. A regular routing configuration change occurs when the Hub Transport server or Edge Transport server renews its Kerberos token with an Active Directory domain controller. The renewal of the Kerberos token causes a recalculation of the routing table and the creation of a new routing table log. The Kerberos token is renewed every six hours. The time interval specified by the RoutingConfigReloadInterval parameter in the EdgeTransport.exe.config has passed. This value specifies how frequently the routing table is automatically recalculated and logged if no routing configuration changes are detected. The default value is 12 hours. The Microsoft Exchange Transport service is started. Circular logging deletes the oldest log files when the routing table log directory reaches its maximum specified size, or when a log file reaches its maximum specified age. The routing table log files are text files that contain data in XML format. The routing table log files contain a large amount of information. However, the actual file size depends on the size and complexity of the Exchange organization.

Information Written to the Routing Table Log

The routing table log is composed of several sections. Each section identifies a particular element of the Exchange organization, such as connectors, address spaces, or Active Directory sites. The information that's defined in one section is connected to the information that's defined in another section to build a complete routing table for the whole Exchange organization. For large Exchange organizations, the amount of information in the routing table log can be very large. The following table provides a description for each section of the routing table log.

Sections of the routing table log

Section RoutingTables ID Description This section contains basic information about the routing table, such as the following information: The routing table creation date-time in UTC. On Hub Transport servers, the ExchangeTopology ID, ADSiteRelayMap ID, and RoutingGroupRelayMap ID that are being used by the routing table.

On Hub Transport servers, the identity of every Mailbox server, Hub Transport server, Edge Transport server, and legacy Exchange server in the Exchange organization. Each identity maps to a ServerRoute ID. The ConnectorRouting ID for all Send connectors, Receive connectors that are linked to Send connectors on the local server, foreign connectors, and legacy gateway connectors in the Exchange organization. Legacy gateway connectors exist on the server that's running Exchange Server 2003. Legacy gateway connectors send messages to other messaging servers, such as Lotus Notes or GroupWise.

ExchangeTopology ID

This section contains all the Exchange servers, Active Directory sites, and Active Directory site links that exist in the Exchange organization. This section contains details about every Exchange server in the Exchange organization. This section contains details about every Active Directory site in the Exchange organization. This section contains details about the IP site links that exist in the Exchange organization. This section links an ADTopologyPath ID to each remote Active Directory site that contains an Exchange 2010 Hub Transport server. This section contains details about the least cost routing path from the current Active Directory site to any remote Active Directory site. This section contains the names of all remote Active Directory sites that exist in the Active Directory forest, and a list of Hub Transport servers that exist in each remote Active Directory site. This section maintains the interrelationship between a routing group, the RgTopologySite ID, the RgTopologyPath ID, and the RgConnectorRoute ID. This section contains details about each routing group that exists in the Exchange organization. This section contains details about routing group connectors and SMTP connectors with connected routing groups. This section contains details about remote routing groups and is used to link remote routing groups to a routing group connector or an SMTP connector that contains connected routing groups. This section contains the route to the first hop routing group that can be used to route mail to a remote routing group. This section lists every Hub Transport server, Edge Transport server, Mailbox server, and legacy Exchange server object in the Exchange organization, and associates a route to that server. This section contains routes to all Send connectors, foreign connectors, and legacy gateway connectors. It also contains a mapping of Receive connectors on the local server that are linked to Send connectors on the local server. When a Receive connector is linked to a Send connector, all messages that arrive on the linked Receive connector are immediately forwarded out through the corresponding Send connector. This section lists all the Send connectors, foreign connectors, and legacy gateway connectors in the Exchange organization, and associates a route to the connector. This section contains details about every Send connector that exists in the Exchange organization.

TopologyServer ID TopologySite ID TopologySiteLink ID ADSiteRelayMap ID ADTopologyPath ID TargetSite ID

RoutingGroupRelayMap ID

RgTopologySite ID RgTopologyLink ID RgTopologyPath ID

RgConnectorRoute ID ServerRoute ID

ConnectorRouting ID

ConnectorRoute ID

SmtpSendConnectorConfig ID AddressSpace ID

This section lists all the address spaces that are configured on every Send connector, foreign connector, or legacy gateway connector in the Exchange organization. This section lists details about every legacy gateway connector that exists in the Exchange organization. Legacy gateway connectors exist on servers that are running Exchange 2003. This section contains details about every foreign connector that exists in the Exchange organization. Foreign connectors are homed on Exchange 2010 Hub Transport servers and use a Drop directory to send messages to non-SMTP messaging servers. This section maps an address type to an SmtpConnectorIndex ID. This section contains the SMTPIndexNode ID of the root index that's supported by this SMTPConnectorIndex ID. This section contains the X400IndexNode ID of the root index that's supported by this X400ConnectorIndex ID. This section contains the IndexEntry ID of the root index that's supported by this GenericConnectorIndex ID. This section contains the SMTPIndexNode ID, which represents a part of an SMTP address space. The values of the index nodes are combined to form the complete SMTP address space. For example, the domain exchange.contoso.com has the following four index nodes: The root SMTP index node The com SMTP index node The contoso SMTP index node The exchange SMTP index node

LegacyGatewayConnector ID ForeignConnector ID

AddressTypeRouting ID SmtpConnectorIndex ID X400ConnectorIndex ID GenericConnectorIndex ID SMTPIndexNode ID

X400IndexNode ID

This section contains the X400IndexNode ID, which represents a part of an X.400 address space. The values of the index nodes are combined to form the complete X.400 address space.

IndexEntry ID

This section contains the IndexEntry ID, which represents a part of a non-SMTP address space, such as Lotus Notes or fax. The values of the index entries are combined to form the complete non-SMTP address space. This section links an address space cost to a connector route.

ConnectorRouteWithCost ID

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Transport Pipeline

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-04-28 In Microsoft Exchange Server 2010, the transport pipeline is a collection of Exchange 2010 server roles, connections, components, and queues that work together to route all messages to the categorizer on a Hub Transport server inside the organization. Messages from outside the organization enter the transport pipeline through a Receive connector on an Edge Transport server and are then routed to a Hub Transport server inside the organization. Messages inside the organization enter the transport pipeline on a Hub Transport server in one of the following ways:

Through a Receive connector From the Pickup directory or the Replay directory By direct placement in the Submission queue by the store driver Through agent submission Every message that's sent or received by an Exchange 2010 client must be categorized on a Hub Transport server before it can be routed and delivered. After a message has been categorized, it's put in a delivery queue for delivery to a mailbox in the same Active Directory site as the Hub Transport server on which the message was categorized or for routing to a recipient in a different Active Directory site or forest, or to a recipient outside the organization. The Exchange 2010 transport pipeline consists of the following components and processes:

SMTP Receive When messages are received at the Edge Transport server, anti-spam and antivirus agents filter connections and message contents, and help identify the sender and the recipient of a message while the message is being accepted into the organization. When messages are received at a Hub Transport server, transport rules are applied and, if anti-spam and antivirus agents are configured, these agents provide an additional layer of anti-spam and antivirus protection. The SMTP session has a series of events that work together in a specific order to validate the contents of a message before it's accepted into the organization. After a message has passed completely through SMTP Receive and isn't rejected by receive events or by an anti-spam and antivirus agent, it's put in the Submission queue. Submission Submission is the process of putting messages into the Submission queue. The categorizer picks up one message at a time for categorization. There are four types of submission: SMTP submission through a Receive connector. Submission through the Pickup directory or the Replay directory. These directories exist on the Hub Transport server or Edge Transport server. Correctly formatted message files that are copied into the Pickup directory or the Replay directory are put directly into the Submission queue. Submission by the store driver, which picks up messages from a senders Outbox as they're sent. Submission by an agent. On the Edge Transport server, submission is generally only through the Receive connector. On the Hub Transport server, submission can occur through a Receive connector, Pickup directory, Replay directory, or store driver. Categorizer The categorizer picks up one message at a time from the Submission queue. On the Edge Transport server, categorization is a short process in which the message is put directly in the delivery queue. From the delivery queue, the message is routed to a computer that's running a Hub Transport server role in the organization. On the Hub Transport server, the categorizer completes the following steps: Recipient resolution, which includes top-level addressing, expansion, and bifurcation Routing resolution Content conversion Additionally, mail flow rules that are defined by the organization are applied. After messages have been categorized, they're put into a delivery queue. A mailbox delivery queue delivers the message to a local mailbox by using the store driver. A remote delivery queue delivers the message to a remote recipient through a Send connector. Local Delivery Only messages that are sent to a recipient with a mailbox in the same Active Directory site as the Hub Transport server on which categorization occurred are delivered locally. In this case, local delivery means delivery in the same Active Directory site. All messages delivered locally are picked up from a delivery queue by the store driver and put in the recipients inbox on a Mailbox server. SMTP Send Messages that are sent to recipients in Active Directory sites that differ from the computer that's running a Hub Transport server role on which categorization occurred are delivered remotely or outside the organization. All messages that are sent to a different Active Directory site, to a mailbox that resides on a computer that's running an earlier version of Exchange, or to a mailbox that resides in a different Active Directory forest must be routed through a Send connector to a Hub Transport server that can deliver the message to the intended recipient. All messages that require delivery through the Internet must be routed through a Send connector to an Edge Transport server that can send messages to the Internet for delivery outside the organization. Client Access and Unified Messaging Scenarios Several client access scenarios and Unified Messaging scenarios don't interact directly with the transport pipeline. Users of Microsoft Outlook 2007, Outlook 2003, Outlook Web App, Outlook Voice Access, and Exchange ActiveSync interact directly with the Client Access server role, Unified Messaging server role, and Mailbox server role to access their mailbox. In each case, when mail is sent, the message is put in the senders Outbox directly on the Mailbox server by Outlook or the Client Access server on behalf of the sender. Note: Outlook Voice Access requires interaction with the Client Access server and with the Mailbox server through the Unified Messaging server. After the message is put in the senders Outbox, the store driver is alerted by the Microsoft Exchange Mail Submission service, which retrieves the message from the senders Outbox, and then puts it into the Submission queue on a Hub Transport server in the same Active Directory site as the mailbox from which the message was retrieved. The following figure shows the relationships among the components in the Exchange 2010 transport pipeline.

Looking for management tasks related to managing transport servers? See Managing Transport Servers. 2010 Microsoft Corporation. All rights reserved.
2013 Microsoft. All rights reserved.

Understanding Transport Policy and Compliance Agents

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-04-28 Many organizations are obligated by legal, regulatory, or business process requirements to process, filter, modify, and store e-mail messages transferred to and from the organization and the Internet, in addition to internal communications between individuals in the organization. The transport policy and compliance infrastructure of Microsoft Exchange Server 2010 provides a set of rules that govern how e-mail messages are stored and processed based on a set of requirements. The following important features help you comply with these legal, regulatory, and business process requirements more easily:

Transport rules agents There are two transport rules agents in Exchange 2010. The Transport Rule agent runs on Hub Transport servers and helps you meet regulatory and corporate policy requirements. The Edge Rule agent runs on the Edge Transport server and helps you protect your organization from unsolicited commercial e-mail (spam) and viruses. For more information about transport rules agents and specific scenarios where they might be used, see the following topics: Understanding Transport Rules Understanding How Transport Rules Are Applied Understanding Ethical Walls Journaling agent The Journaling agent helps you configure how Exchange enforces e-mail retention policies on messages sent or received by departments or individuals in your organization, to and from recipients outside your organization, or both. Important: In Exchange 2010, the Journaling agent is a built-in agent. Built-in agents aren't included in the list of agents returned by the Get-TranpsortAgent cmdlet. For more details, see Understanding Transport Agents. For more information about the Journaling agent, journal reports, and journaling in a mixed Exchange Server 2003 and Exchange Server 2007 organization or in a mixed Exchange 2010 and Exchange Server 2007 organization, see the following topics: Understanding Journaling Understanding Journal Reports Protecting Journal Reports Understanding How to Manage Journal Reports Understanding Journaling in a Mixed Exchange 2003 and Exchange 2010 Environment Export and Import Exchange 2007 Journal Rules Information Rights Management (IRM) agents There are three IRM agents in Exchange 2010. The Encryption agent IRM-protects messages flagged by the Transport Rule agent on Hub Transport servers. The Pre-licensing agent inserts a use license in messages that are IRM-protected by using the organization's Active Directory Rights Management Services (AD RMS) cluster. The Decryption agent decrypts IRM-protected messages to allow other transport agents access to message content, and for including a plaintext copy of the message in journal reports for archival and discovery. For more information about IRM agents, see the following topics: Understanding Information Rights Management Understanding Transport Protection Rules Understanding Transport Decryption Understanding Journal Report Decryption

Using Exchange Hosted Services

Policy and compliance features are enhanced by or are also available as services from Microsoft Exchange Hosted Services. Exchange Hosted Services is a set of four distinct hosted services:

Hosted Filtering, which helps organizations protect themselves from e-mail-borne malware Hosted Archive, which helps them satisfy retention requirements for compliance Hosted Encryption, which helps them encrypt data to preserve confidentiality Hosted Continuity, which helps them preserve access to e-mail during and after emergency situations These services integrate with any on-premises Exchange servers that are managed in-house or Hosted Exchange e-mail services that are offered through service providers. For more information about Exchange Hosted Services, see Microsoft Exchange Hosted Services.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Transport Queues

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-04-28 This topic provides an overview of queues in Microsoft Exchange Server 2010 and the queue management tasks that administrators can perform. Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents Overview Queue Database Files Queue Management Message Retry, Resubmit, and Expiration Intervals

Overview

A queue is a temporary holding location for messages that are waiting to enter the next stage of processing. Each queue represents a logical set of messages that a transport server processes in a specific order. The Exchange Management Shell and Queue Viewer support two types of interaction with queues. You can use these interfaces to view the status and contents of queues and detailed message properties. You can also use these interfaces to perform actions that modify queues or the messages in the queues. Exchange 2010 uses an Extensible Storage Engine (ESE) database for queue storage. Formerly known as JET, ESE is a method that defines a low-level API to the underlying database structures in Exchange. Messages that come from and go to the Internet are queued at the computers that have the Edge Transport server role installed. Messages in transit within the Exchange 2010 organization are queued at the computers that have the Hub Transport server role installed.

Types of Queues
The routing of a message determines the type of queue in which a message is stored. The following types of queues are used in Exchange 2010:

Submission queue A persistent queue that's used by the categorizer to gather all messages that have to be resolved, routed, and processed by transport agents. The categorizer is a component of Exchange transport that processes all inbound messages and determines what to do with the messages based on information about the intended recipients. In Exchange 2010, the Edge Transport server uses the categorizer to route the message to the appropriate destination. The Hub Transport server uses the categorizer to expand distribution lists and to identify alternative recipients and forwarding addresses. After the categorizer retrieves full information about recipients, it uses that information to apply policies, route the message, and perform content conversion. All messages that are received by a transport server enter processing in the Submission queue. Messages are submitted through a Receive connector, the Pickup directory, or the store driver. The categorizer retrieves messages from this queue and, among other things, determines the location of the recipient and the route to that location. After categorization, the message is moved to a delivery queue or to the unreachable queue. Each Exchange 2010 transport server has only one Submission queue. Messages that are in the Submission queue can't be in other queues at the same time. Mailbox delivery queue The mailbox delivery queues hold messages that are being delivered to a Mailbox server by using encrypted Exchange RPC. Mailbox delivery queues exist on Hub Transport servers only. Mailbox delivery queues hold messages that are being delivered to mailbox recipients whose mailbox data is stored on a Mailbox server that's located in the same site as the Hub Transport server. More than one mailbox delivery queue can exist on a Hub Transport server. The next hop for a mailbox delivery queue is the distinguished name of the mailbox store. Remote delivery queue Remote delivery queues hold messages that are being delivered to a remote server by using SMTP. Remote delivery queues can exist on both Hub Transport servers and Edge Transport servers, and more than one remote delivery queue can exist on each server. Each remote delivery queue contains messages that are being routed to recipients that have the same delivery destination. On an Edge Transport server, these destinations are external SMTP domains or SMTP connectors. On a Hub Transport server, these destinations are outside the Active Directory site in which the Hub Transport server is located. Remote delivery queues are dynamically created when they're required and are automatically deleted from the server when they no longer hold messages and the configurable expiration time has passed. By default, a remote delivery queue is deleted three minutes after the last message has left the queue. The next hop for a remote delivery queue is an SMTP domain name, a smart host name or IP address, or an Active Directory site name. Poison message queue The poison message queue is a special queue that's used to isolate messages that are detected to be potentially harmful to the Exchange 2010 system after a server failure. Messages that contain errors that are potentially fatal to the Exchange system are delivered to the poison message queue. This queue is typically empty, and if no poison messages exist, the queue doesn't appear in the queue viewing interfaces. The poison message queue is always in a ready state. By default, all messages in this queue are suspended. The messages can be deleted if they're considered to be harmful to the system. If the event that caused the message to enter the poison message queue is determined to be unrelated to the message, delivery of the message can be resumed. When delivery is resumed, the message enters the Submission queue. Unreachable queue Each transport server can have only one Unreachable queue. The Unreachable queue contains messages that can't be routed to their destinations. Typically, an unreachable destination is caused by configuration changes that have modified the routing path for delivery. Regardless of destination, all messages that have unreachable recipients reside in this queue. The following table lists the queues that exist on a Hub Transport server or Edge Transport server and their characteristics.

Queues that exist on a Hub Transport server or Edge Transport server

Queue name Mailbox delivery queue Server role Hub Transport Number of queues on the server One queue for every unique destination Mailbox server

Poison message queue

Edge Transport Hub Transport Edge Transport Hub Transport Edge Transport Hub Transport Edge Transport Hub Transport

Remote delivery queue

Edge Transport: One queue for every unique destination SMTP domain or smart host Hub Transport: One queue for every unique remote Active Directory site 1

Submission queue

Unreachable queue

When a message is received by transport, a transport mail item is created and saved to the database. A unique identifier is assigned to the transport mail item when it enters the database. If a message, or transport mail item, is being routed to more than one recipient, the item can have more than one destination. Each destination represents a separate routing solution for the transport mail item, and each routing solution causes a routed mail item to be created. The routed mail item is a reference to the transport mail item and is the unit of operation for queuing actions. If a transport mail item has more than one routing solution, more than one routed mail item references the same transport mail item. A message that's being sent to recipients in two different domains appears as two distinct messages in the delivery queues, even if only one transport mail item is in the database.

About the Poison Message Queue and the Unreachable Queue

The categorizer sends messages to the Unreachable queue when there's no known route to their destinations. Typically, an unreachable destination is caused by a configuration error that affects the delivery path. For example, the messages will be sent to the Unreachable queue if the following conditions are true:

There are messages in the remote delivery queue named Contoso.com. You delete the Send connector that's used to reach the Contoso.com domain. By default, the messages in the Unreachable queue have the status of Ready. Messages in the Unreachable queue are never automatically resubmitted. Messages remain in the Unreachable queue until they're manually resubmitted by an administrator, removed by an administrator, or the value specified in the MessageExpirationTimeOut parameter passes. The poison message queue contains messages that are determined to be potentially harmful to the Exchange 2010 server after a server failure. The messages may be genuinely harmful in their content and format. Alternatively, they may be the results of a poorly written agent that has caused the Exchange server to fail when it processed the supposedly bad messages. All messages in the poison message queue are in a permanently suspended state. The poison message queue can't be resubmitted with the Retry-Queue cmdlet with the Resubmit parameter. To resubmit the messages in the poison message queue, you can use Queue Viewer or the Resume-Message cmdlet to resume the messages. The messages in the poison message queue are never automatically resumed or expired. Messages remain in the poison message queue until they're manually resumed or removed by an administrator. Return to top

Queue Database Files

All the different queues are stored in a single ESE database. By default, this queue database is located at C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue. Like any ESE database, the queue database uses log files to accept, track, and maintain data. To enhance performance, all message transactions are written first to log files and memory, and then to the database file. The checkpoint file tracks the transaction log entries that have been committed to the database. During an ordinary shutdown of the Microsoft Exchange Transport service, uncommitted database changes that are found in the transaction logs are always committed to the database. Circular logging is used for the queue database. This means that the history of committed transactions that are found in the transaction logs isn't maintained. Any transaction logs that are older than the current checkpoint are immediately and automatically deleted. Therefore, the transaction logs can't be replayed for queue database recovery from backup. The following table lists the files that constitute the queue database.

Files that constitute the queue database

File Mail.que Tmp.edb Trn*.log Description This queue database file stores all the queued messages. This temporary database file is used to verify the queue database schema on startup. This transaction log records all changes to the queue database. Changes to the database are first written to the transaction log and then committed to the database. Trn.log is the current active transaction log file. Trntmp.log is the next provisioned transaction log file that's created in advance. If the existing Trn.log transaction log file reaches its maximum size, Trn.log is renamed to Trnnnnn.log, where nnnn is a sequence number. Trntmp.log is then renamed Trn.log and becomes the current active transaction log file. This checkpoint file tracks the transaction log entries that have been committed to the database. This file is always in the same location as the mail.que file. These reserve transaction log files act as placeholders. They're only used when the hard disk that contains the transaction log runs out of space to stop the queue database cleanly.

Trn.chk

Trnres00001.jrs Trnres00002.jrs

Options for Configuring the Queue Database

You can't use the Exchange Management Console (EMC) or the Shell to configure the queue database. You configure the queue database by modifying the EdgeTransport.exe.config file. The EdgeTransport.exe.config file is an XML application configuration file that's associated with the EdgeTransport.exe file. For more information about the EdgeTransport.exe.config file, see Understanding the EdgeTransport.exe.Config File. The <appSettings> section of the EdgeTransport.exe.config file is where you can add new configuration options or modify existing configuration options. Many configuration options that are completely unrelated to the queue database are also available. However they're outside the scope of this topic and won't be discussed. The configuration options for the queue database that are available in the EdgeTransport.exe.config file are described in the following table.

Message queue database configuration options that are available in the EdgeTransport.exe.config file
Parameter name QueueDatabaseBatchSize Description This parameter specifies the number of database I/O operations that can be grouped together before they're executed. The default value is 40. This parameter specifies the maximum time in milliseconds that the database will wait for multiple database I/O operations to group before it executes them. The database I/O operations are executed without waiting for any more if the following conditions are true: The number of database I/O operations that's specified by the QueueDatabaseBatchSize parameter hasn't been reached. The time specified by the QueueDatabaseBatchTimeout parameter has passed. The default value is 100. QueueDatabaseMaxConnections QueueDatabaseLoggingBufferSize This parameter specifies the number of ESE database connections that can be open. The default value is 4. This parameter specifies the memory that's used to cache the transaction records before they're written to the transaction log file. The default value is 5242880 bytes. This parameter specifies the maximum size of a transaction log file. When the maximum log file size is reached, a new log file is opened. The default value is 5242880 bytes. This parameter specifies the default directory for the queue database log files. The default value is C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue. Before you change the queue database logging directory, make sure that the new directory exists. Also make sure that the following file permissions are applied to it: Network Service: Full Control; System: Full Control; Administrators: Full Control. This parameter specifies the maximum number of background cleanup work items that can be queued to the database engine thread pool at any time. The default value is 32. The parameter enables or disables scheduled online defragmentation of the mail queue database. The default value is $true. This parameter specifies the time of day in 24 hour format to start the online defragmentation of the mail queue database. To specify a value, enter the value as a time: hh:mm:ss, where h = hours, m = minutes, and s = seconds. The default value is 1:00:00, which is 01:00 or 1:00 A.M. This parameter specifies the time that span the online defragmentation task is allowed to run. Even if the defragmentation task doesn't finish in the time specified, the queue database is left in a consistent state. To specify a value, enter the value as a time span: hh:mm:ss, where h = hours, m = minutes, and s = seconds. The default value is 3:00:00. This parameter specifies the default directory for the queue database files. The default value is C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue. Before you change the queue database directory, make sure that the new directory exists. Also make sure that the following file permissions are applied to it: Network Service: Full Control; System: Full Control; Administrators: Full Control.

QueueDatabaseBatchTimeout

QueueDatabaseLoggingFileSize

QueueDatabaseLoggingPath

QueueDatabaseMaxBackgroundCleanupTasks

QueueDatabaseOnlineDefragEnabled

QueueDatabaseOnlineDefragSchedule

QueueDatabaseOnlineDefragTimeToRun

QueueDatabasePath

Return to top

Queue Management
When you experience a mail flow problem or an influx of spam, you can perform operations that modify the status of queues and messages that are located in queues. You can perform an action on a single object, or you can perform a bulk action on more than one selected object. Use the Queue Viewer graphical user interface and commands in the Shell in Exchange 2010 to retrieve information about messages and delivery queues. After you retrieve this information, you can select the queues and messages that you want to manage. You use Queue Viewer or commands in the Shell to create filter criteria to identify the queues and messages that you want to manage. The filter criteria are based on the following attributes:

Queue state Queue properties Message state Message properties For more information about how to filter queues, see Filter Queues. For more information about how to filter messages, see Filter Messages in Queues.

Queue Management Tasks

You use Queue Viewer or commands in the Shell to view information about queues and messages. You can also use these tools to perform the following actions:

Suspend queue This action temporarily prevents delivery of messages that are currently in the queue. The queue continues to accept new messages, but no messages leave the queue. For more information, see Suspend Queues. Resume queue This action reverses the effect of the suspend queue action and enables delivery of queued messages to resume. For more information, see Resume Queues. Retry queue When a connection to the next hop for a queue fails, a retry timer is set. The retry timer schedules subsequent connection tries. The retry queue action overrides the next scheduled connection attempt and tries to connect to the next hop immediately. If no connection is made, the next retry time is reset. For more information, see Retry Queues. You can also use the Retry-Queue cmdlet together with the Resubmit parameter to cause the messages in the queue to be resubmitted to the Submission queue and to go back through the categorization process. You can manually resubmit messages that have the following status: Mailbox delivery queues or remote delivery queues that have the status of Retry. The messages in the queues must not be in the Suspended state. Messages in the Unreachable queue that aren't in the Suspended state. Messages in the poison message queue. For more information, see Resubmit Messages in Queues. Suspend message This action temporarily prevents delivery of a message. You can use the suspend message action to prevent delivery of a message to all the recipients in a specific queue or to all recipients in all queues. For more information, see Suspend Messages. Resume message This action reverses the effect of the suspend message action and enables delivery of queued messages to resume. You can use the resume message action to resume delivery of a message to all the recipients in a specific queue or to all recipients in all queues. You can also use this action to resubmit messages in the poison message queue. For more information, see Resume Messages. Remove message This action permanently prevents delivery of a message. You can use the remove message action to prevent delivery of a message to any recipients in a specified queue or to all recipients in all queues. You can also configure the remove message action to send a non-delivery report (NDR) to the sender when the message is removed. For more information, see Remove Messages from Queues. Export message This action copies a message to the file path that you specify. The messages aren't deleted from the queue, but a copy of the message is saved to a file location. This enables administrators or officials in an organization to later examine the messages. Before you export a message, you must suspend the message in the queue so that typical delivery doesn't continue during the export process. The export format is compatible with e-mail applications such as Microsoft Office Outlook. Save the message in .eml format to make sure that the operating system associates the file with an e-mail application. For more information, see Export Messages from Queues.

Queue Filtering Scenarios

Filtering generates different views of the queues. You use the queue properties as filter options. By specifying filter criteria, you can quickly locate queues and take action on them. The following scenarios are examples of how you can use queue filtering to manage message flow:

You receive a message from the Microsoft System Center Operations Manager that indicates that a queue length has exceeded the established threshold. You want to investigate whether a server-wide mail flow problem exists. You can create a filter to view all the queues that have a message count that exceeds what you consider typical. If a mail flow problem is indicated, you can select all the queues in the filter results and suspend the queues while you continue to investigate. You suspend several queues to investigate the cause of mail flow problems. You determine that the problem was caused by an incorrect connector configuration and is now fixed. You can create a filter to view all the queues that have a status of Suspended, and then select all the queues in the filter results and resume the queues.

Queue Properties to Use When Filtering Queues

You can use the queue properties to create a filter and locate queues that meet specified criteria. The following table lists the queue properties by which you can filter and the valid values for those properties.

Queue properties
Queue Viewer queue property Delivery Type Shell queue property Property type

Value

DeliveryType

Enumeration

This value is determined by the next hop selection. The next hop selection identifies where messages are queued for delivery. To use the delivery type property in a filter, you must use the constant values that are assigned to each type. The delivery type can be one of the following values: DNSConnectorDelivery The messages are queued for delivery to an external recipient by using an SMTP connector that's located on the local server and that's configured to use Domain Name System (DNS) for routing resolution. NonSmtpGatewayDelivery The messages are queued for delivery to an external recipient by using a non-SMTP connector on the local server. SmartHostConnectorDelivery The messages are queued for delivery to an external recipient by using an SMTP connector that's located on the local server and that's configured to use a smart host for routing resolution. SmtpRelayWithinAdSitetoEdge The messages are queued for delivery to an external recipient by using an SMTP connector that's located on an Edge Transport server that's subscribed to the local Active Directory site. MapiDelivery The messages are queued for delivery to recipients that have mailboxes that are located on a Mailbox server that's located in the local Active Directory site. SmtpRelayWithinAdSite The messages are queued for delivery to a Hub Transport server that's located in the same Active Directory site as the local server. The destination server can be the source server for an SMTP connector, the source server of a routing group connector, or an expansion server. SmtpRelaytoRemoteAdSite The messages are queued for delivery to a server that's located in a remote Active Directory site. The destination server can be the source server for a connector that's configured to transport messages for external recipients, an expansion server, or a Hub Transport server that delivers messages addressed to mailbox recipients that are located in the remote Active

Directory site. SmtpRelaytoTiRg The messages are queued for delivery to an Exchange Server 2003 routing group. The destination server can be the source server for a connector that's configured to transport messages for external recipients, an expansion server, or an Exchange 2003 bridgehead server that delivers messages addressed to mailbox recipients that are located in the routing group. Undefined The messages are located in the Submission queue, and the next hop destination hasn't yet been resolved. Unreachable The messages are located in the Unreachable queue, and a route to the recipient couldn't be established.

Identity

Identity

QueueIdentity

This value specifies the identity of the queue. Enter the queue identity in the form of Server\destination, where destination is a remote domain, Mailbox server, persistent queue name, or the integer that identifies this queue in the queuing database. This value specifies a text string of the last error that was recorded for a queue. This value specifies the time of the last connection attempt for a queue that has a status of Retry.

Last Error Last Retry Time Message Count Next Hop Connector Next Hop Domain

LastError LastRetryTime

String DateTime

MessageCount

Ulong

This value is expressed as an integer that represents the number of items in the queue.

NextHopConnector

GUID

This value is expressed as a system GUID and is the GUID of the connector that was used to create the queue. This value specifies the next destination of a delivery queue. The next hop domain can be expressed as follows: Remote SMTP domain name Exchange server name Connector name Routing group Active Directory site name Mailbox server fully qualified domain name (FQDN)

NextHopDomain

String

Next Retry Time Status

NextRetryTime

DateTime

This value specifies the time of the next connection attempt for a queue that has a status of Retry.

Status

Enumeration

This value specifies the current queue status. A queue can have one of the following status values: Active Suspended Ready Retry

Operators to Use When Filtering Queues

When you create a queue filter, you must include an operator for the property value to match. The following table shows the comparison operators that you can use in a filter expression and how each operator functions.

Filter expression operators

Operator Shell value -eq Function Shell code example

Equals

This operator is used to specify that the results must exactly match the property value that's supplied in the expression.

To display a list of all queues that have a status of Retry: Get-Queue -Filter {status -eq "retry"}

Does Not Equal

-ne

This operator is used to specify that the results shouldn't match the property value that's supplied in the expression.

To display a list of all queues that don't have a status of Active: Get-Queue -Filter {status -ne "active"}

Greater Than

-gt

This operator is used with properties where the value is expressed as an integer. The filter results only include queues where the value of the specified property is greater than the value that's supplied in the expression.

To display a list of queues that currently contain more than 1,000 messages: Get-Queue -Filter {messagecount -gt 1000}

Greater Than or Equals

-ge

This operator is used with properties where the value is expressed as an integer. The filter results only include queues where the value of the specified property is greater than or equal to the value that's supplied in the expression.

To display a list of queues that currently contain 1,000 or more messages: Get-Queue -Filter

{messagecount -ge 1000} Less Than -lt This operator is used with properties where the value is expressed as an integer. The filter results only include queues where the value of the specified property is less than the value that's supplied in the expression. To display a list of queues that currently contain less than 1,000 messages: Get-Queue -Filter {messagecount -lt 1000} Less Than or Equals -le This operator is used with properties where the value is expressed as an integer. The filter results only include queues where the value of the specified property is less than or equal to the value supplied in the expression. To display a list of queues that currently contain 1,000 or fewer messages: Get-Queue -Filter {messagecount -le 1000} Contains -like This operator is used with properties where the value is expressed as a text string. The filter results only include queues where the value of the specified property contains the text string that's supplied in the expression. You can include the wildcard character (*) in a -like expression that's applied to a text string field, but not with a field that has the enumeration type. To display a list of delivery queues that have a destination to any SMTP domain that ends in Contoso.com: Get-Queue -Filter {identity -like "*Contoso.com"} You can specify multiple expressions in your queue filter by using the -and operator in the Shell or by adding multiple expressions in Queue Viewer. Queues must meet all criteria to be included in the result set. For example, the results of the following command will display a list of queues that have a destination to any SMTP domain name that ends in Contoso.com and that currently contain more than 500 messages.

Get-Queue -Filter {Identity -like "*Contoso.com*" -and MessageCount -gt 500}

Message Filtering Scenarios

Filtering generates different views of the messages in queues. By specifying filter criteria, you can quickly locate messages and take action on them. When an e-mail message is sent to multiple recipients, the message may be located in multiple queues. When you filter by message properties, you can locate messages across all queues. The following scenarios are examples of how you might use message filtering to manage mail flow:

The Submission queue on the computer that has the Edge Transport server role installed has a high volume of messages that are queued for delivery. Many of the messages have the same subject. Therefore, you suspect that spam is being sent to your organization. You can create a filter to view all the messages that meet the subject criteria. If you determine that the messages are spam, you can select them all and delete them from the delivery queue without sending an NDR. A user reports that mail flow is slow. You examine the queues and see that many messages that have random subjects appear to be coming from a single domain. You can create a filter to view all the queued messages from that domain. If you determine that the messages are spam, you can select them all and delete them from the queues without sending an NDR.

Message Properties to Use When Filtering Messages

You can use message properties to create a filter and locate messages that meet specified criteria. The following table lists the message properties by which you can filter and the values that are associated with those properties.

Message properties
Queue Viewer message property Date Received Expiration Time From Address Identity Shell message property

Property type

Value

DateReceived

DateTime

This value specifies the time stamp when the message was received by the server that holds the queue in which the message is located. This value specifies the time stamp when the message will expire and be deleted from the queue if the message can't be delivered. This value specifies the SMTP address of the sender of the message.

ExpirationTime

DateTime

FromAddress

SMTP Address

Identity

Integer

This value is an integer that represents a particular message. The message identity is assigned by the queuing database when the message is received for processing. You can include an optional server and queue identity to identify a unique instance of the message. This value can be expressed as follows: Server\QueueId\MessageId Server\Poison\MessageId MessageId

Server\MessageId

Internet Message ID

InternetMessageId

String

This value specifies the value of the Message-ID: message header field that's located in the message header. The value of this property is expressed as a GUID followed by the SMTP address of the sending server, as in this example: 67D754D6103DC4FB3BA6BC7205DACABA61231@exchange.contoso.com

Last Error Message Source Name Queue ID

LastError MessageSourceName

String String

This value specifies a text string of the last error that was recorded for a message. This value specifies a text string of the name of the component that submitted this message to the queue.

Queue

QueueIdentity

The value of this property specifies the identity of the queue that holds the message. Enter the queue identity in the form of Server\destination, where destination is a remote domain, Mailbox server, persistent queue name, or the queuing database identifier. The database identifier is represented as an integer and can be determined by viewing the message properties. This value specifies the number of times that delivery of a message to a destination was tried.

Retry Count SCL

RetryCount

Integer

SCL

Integer

The value of the spam confidence level (SCL) property specifies the SCL of the message. Valid SCL entries are integers from 0 through 9. An empty SCL property value indicates that the message hasn't been processed by the Content Filter agent. This value specifies the size of the message. This value specifies the IP address of the external server that submitted the message to the Exchange organization. This value specifies the current message status. A message can have one of the following status values: Active If the message is in a delivery queue, the message is being delivered to its destination. If the message is in the Submission queue, the message is being processed by the categorizer. Suspended The message was suspended by the administrator. PendingRemove The message was deleted by the administrator, but was already in delivery. The message will be deleted if the delivery ends in an error that causes the message to reenter the queue. Otherwise, delivery will continue. PendingSuspend The message was suspended by the administrator, but was already in delivery. The message will be suspended if the delivery ends in an error that causes the message to reenter the queue. Otherwise, delivery will continue. Ready The message is waiting in the queue and is ready to be processed. Retry The last connection attempt for the queue in which this message is located failed. The message is waiting for the next queue retry.

Size (KB) Source IP

Size SourceIP

ByteQuantifiedSize IP Address

Status

Status

Enumeration

Subject

Subject

String

This value specifies the subject of a message that's expressed as a text string.

Operators to Use When Filtering Messages

When you create a message filter, you must include an operator for the property value to match. The following table shows the comparison operators that you can use in a filter expression and how each operator functions.

Filter expression operators

Operator Shell value -eq Function Shell code example

Equals

This operator is used to specify that the results must exactly match the property value that's supplied in the expression.

To display a list of all messages that have a status of Retry: Get-Message Filter {status -eq "retry"}

Does Not Equal

-ne

This operator is used to specify that the results shouldn't match the property value that's supplied in the expression.

To display a list of all messages that don't have a status of Active: Get-Message Filter {status -ne "active"}

Greater Than

-gt

This operator is used with properties where the value is expressed as an integer. The filter results only include messages where the value of the specified property is greater than the value that's supplied in the expression.

To display a list of messages that currently have a retry count that's more than 3: Get-Message -

Filter {retrycount -gt 3} Greater Than or Equals -ge This operator is used with properties where the value is expressed as an integer. The filter results only include messages where the value of the specified property is greater than or equal to the value that's supplied in the expression. To display a list of messages that currently have a retry count that's 3 or more: Get-Message Filter {retrycount -ge 3} Less Than -lt This operator is used with properties where the value is expressed as an integer. The filter results only include messages where the value of the specified property is less than the value that's supplied in the expression. To display a list of messages that have an SCL that's less than 6: Get-Message Filter {SCL -lt 6} Less Than or Equals -le This operator is used with properties where the value is expressed as an integer. The filter results only include messages where the value of the specified property is less than or equal to the value that's supplied in the expression. To display a list of messages that have an SCL that's 6 or less: Get-Message Filter {SCL -le 6} Contains -like This operator is used with properties where the value is expressed as a text string. The filter results only include messages where the value of the specified property contains the text string that's supplied in the expression. You can include the wildcard character (*) in a -like statement that's applied to a text string field, but not a field that has the enumeration type. To display a list of messages that have a subject that contains the text "payday loan": Get-Messages Filter {subject like "*payday loan*"} You can specify a filter that evaluates multiple expressions by using the -and comparison operator in the Shell or by adding multiple expressions in Queue Viewer. To be included in the result set, messages must meet all conditions of the filter. For example, the results of the following command will display a list of messages that are sent from any e-mail address that has a domain name that ends in Contoso.com and that have an SCL that's greater than 5.

Get-Message -Filter {FromAddress -like "*Contoso.com*" -and SCL -gt 5}

Return to top

Message Retry, Resubmit, and Expiration Intervals

Messages that can't be successfully delivered are subject to various retry, resubmit, and expiration deadlines based on the message's source and destination. Retry is a renewed connection attempt with the destination domain, smart host, or Mailbox server. Resubmit is the act of sending messages back to the Submission queue for the categorizer to reprocess. The message is said to time-out or expire after all delivery efforts have failed over a specified period of time. After a message expires, the sender is notified of the delivery failure. Then the message is deleted from the queue. In all three cases of retry, resubmit, or expire, you can manually intervene before the automatic actions are performed on the messages.

Configuration Options for Message Retry

When a transport server can't connect to the next hop, the queue is put in a status of Retry. Connection attempts continue until the queue expires or a connection is made.

Configuration Options for Automatic Message Retry

The configuration options that are available for message retry intervals are described in the following table.

Configuration options that are available for message retry intervals

Parameter name QueueGlitchRetryCount Default value 4 Where to configure EdgeTransport.exe.config Description This parameter specifies the number of connection attempts that are immediately tried when a transport server has trouble connecting with the destination server. Such connection problems are typically caused by very brief network outages. Typically, you don't have to modify this parameter unless the network is unreliable and continues to experience many accidentally dropped connections. This parameter controls the connection interval between each connection attempt that's specified by the QueueGlitchRetryCount parameter. Typically, you don't have to modify this parameter unless

QueueGlitchRetryInterval

1 minute

EdgeTransport.exe.config

the network is unreliable and continues to experience many accidentally dropped connections. TransientFailureRetryCount 6 Set-TransportServer cmdlet or transport server properties in the EMC This parameter specifies the number of connection attempts that are tried after the connection attempts that are controlled by the QueueGlitchRetryCount and QueueGlitchRetryInterval parameters have failed. Connection problems that exhaust the QueueGlitchRetryCount and QueueGlitchRetryInterval parameters can be caused by such things as server restarts or cached DNS lookup failures. This parameter controls the connection interval between each connection attempt that's specified by the TransientFailureRetryCount parameter.

TransientFailureRetryInterval

Hub Transport server: 5 minutes Edge Transport server: 10 minutes

Set-TransportServer cmdlet or transport server properties in the EMC

OutboundConnectionFailureRetryInterval

Hub Transport server: 10 minutes Edge Transport Server: 30 minutes

Set-TransportServer cmdlet or transport server properties in the EMC

This parameter specifies the retry interval for outbound connection attempts that have previously failed. The previously failed connection attempts are controlled by the TransientFailureRetryCount and TransientFailureRetryInterval parameters.

MessageRetryInterval

1 minute

Set-TransportServer cmdlet

This parameter specifies the retry interval for individual messages that have a status of Retry. We recommend that you don't modify the default value unless Microsoft Customer Service and Support advises you to do this. This parameter controls the retry interval for mailbox delivery queues between Hub transport servers.

MailboxDeliveryQueueRetryInterval

5 minutes

EdgeTransport.exe.config

The <appSettings> section of the EdgeTransport.exe.config file is where you can add new configuration options or modify existing configuration options. There are many configuration options available that are completely unrelated to the message retry, resubmit, and expiration intervals. Any configuration options that don't involve these intervals are outside the scope of this topic. For more information about the EdgeTransport.exe.config file, see Understanding the EdgeTransport.exe.Config File. For more information, see Configure Message Retry, Resubmit, and Expiration Intervals.

Configuration Options for Manual Message Retry

When a mailbox delivery queue or a remote delivery queue is in the status of Retry, you can manually force an immediate connection attempt by using Queue Viewer in the EMC or the Retry-Queue cmdlet in the Shell. The manual retry attempt overrides the next scheduled retry time. If the connection isn't successful, the retry interval timer is reset. The delivery queue must be in a status of Retry for this action to have any effect. For more information, see Retry Queues.

Configuration Options for Delay DSN Messages

After each message delivery failure, the Edge Transport server or the Hub Transport server generates a delay delivery status notification (DSN) message and queues it for delivery to the sender of the undeliverable message. This delay DSN message is sent only after a specified delay notification time-out interval, and only if the failed message wasn't successfully delivered during that time. By default, the delay notification time-out interval is 4 hours. This delay prevents the sending of unnecessary delay DSN messages that may be caused by temporary message transmission failures. The sending of delay DSN notification messages can be selectively enabled or disabled for messages that originate inside or outside the Exchange organization. The configuration options that are available for delay DSN notification messages are described in the following table.

Configuration options that are available for delay DSN notification messages
Parameter name Default value 4 hours Location Description

DelayNotificationTimeOut

SetTransportServer

This parameter specifies how long the server waits before it sends a delay DSN message to the message's sender. The value of this parameter should always be greater than the value of the TransientFailureRetryCount parameter multiplied by the value of the TransientFailureRetryInterval parameter. This parameter specifies whether delay DSN messages can be sent to message senders who are outside the Exchange organization. This parameter specifies whether delay DSN messages can be sent to message senders who are inside the Exchange organization.

ExternalDelayDSNEnabled

$true

SetTransportConfig SetTransportConfig

InternalDelayDSNEnabled

$true

For more information, see Configure Message Retry, Resubmit, and Expiration Intervals.

Configuration Options for Message Resubmission

Message resubmission sends undelivered messages back to the Submission queue to be reprocessed by the categorizer.

Automatic Message Resubmission

Undelivered messages are automatically resubmitted if the delivery queue is in the status of Retry and has been unable to successfully deliver any messages for a specified period of time. That period of time is controlled by the MaxIdTimeBeforeResubmit parameter in the EdgeTransport.exe.config application configuration file. By default, the value of the MaxIdTimeBeforeResubmit parameter is 12 hours. Only messages in mailbox delivery queues or remote delivery queues are candidates for automatic resubmission. For more information, see Configure Message Retry, Resubmit, and Expiration Intervals.

Manual Message Resubmission

You can manually resubmit messages that have the following status on a Hub Transport server or an Edge Transport server:

Mailbox delivery queues or remote delivery queues that have the status of Retry. The messages in the queues must not be in the Suspended state. Messages that are in the Unreachable queue and aren't in the Suspended state. Messages that are in the poison message queue. For more information about the poison message queue and the Unreachable queue, see "About the Poison Message Queue and the Unreachable Queue" earlier in this topic. If you want to manually resubmit messages that are located in the mailbox delivery queues, the remote delivery queues, or the Unreachable queue without waiting for the time that's specified by the MaxIdleTimeBeforeResubmit parameter to pass, you must use the Retry-Queue cmdlet with the Resubmit parameter. To manually resubmit messages that are located in the poison message queue, you can use Queue Viewer or the Resume-Message cmdlet to resume the message. For more information, see the following topics:

Resubmit Messages in Queues Resume Messages Another way that you can manually resubmit messages is to suspend the messages, export the messages to text files that have the .eml file name extension, and then copy the .eml files to the Replay directory on any Hub Transport server or Edge Transport server. This resubmission method works for messages that are located in the mailbox delivery queues, remote delivery queues, or the Unreachable queue. Messages that are located in the poison message queue are already in the Suspended state. Messages that are located in the Submission queue can't be suspended or exported. Note: When you export messages from a queue, you don't remove the messages from the queue. After you export the messages and successfully resubmit them by using the Replay directory, you should remove the suspended messages to avoid duplicate message delivery. For more information, see Export Messages from Queues and Resubmit Messages in Queues.

Configuration Options for Message Expiration

The message expiration time-out interval specifies the maximum length of time that an Edge Transport server or a Hub Transport server tries to deliver a failed message. If the message can't be successfully delivered before the expiration time-out interval has passed, an NDR that contains the original message or the message headers is delivered to the sender.

Automatic Message Expiration

The message expiration time-out interval is controlled by the MessageExpirationTimeOut parameter in the Set-TransportServer cmdlet or in the transport server properties in the EMC. By default, the value of the MessageExpirationTimeOut parameter is 2 days. For more information, see the following topics:

Configure Message Retry, Resubmit, and Expiration Intervals Set-TransportServer

Manual Message Expiration

Although you can't manually force messages to expire, you can manually remove messages from any queue, except the Submission queue, with or without an NDR. For more information, see Remove Messages from Queues. Return to top

 2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Transport in a Hybrid Deployment

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-03-16 Service Pack 2 (SP2) for Microsoft Exchange Server 2010 gives you the ability to host some of your Exchange users in an Exchange Online organization hosted in Microsoft Office 365 for enterprises while maintaining a seamless messaging experience for all your users. This topic provides an overview of how Transport servers are used in this scenario. A hybrid deployment requires at least one server running Exchange Server 2010 SP2 in your organization. If youre currently running a previous version of Exchange, you must add one or more Exchange 2010 SP2 servers to act as gateways to the Exchange Online organization. By doing so, you can enable a hybrid deployment without having to upgrade your entire existing deployment. These Exchange 2010 servers are known as the hybrid servers. Your organization must contain one or more hybrid servers with the Hub Transport and Client Access server roles installed. The Mailbox server role is also required for Exchange Server 2003 organizations that need to support the exchange of free/busy information between your on-premises Exchange 2003 mailboxes and Exchange Online mailboxes. Adding this hybrid server to your organization is equivalent to introducing your first Exchange 2010 server to your deployment. To learn more about hybrid deployments, see Understanding Hybrid Deployments with Exchange 2010 SP3. Contents Mail Flow Transport Features Edge Transport in a Hybrid Deployment

Mail Flow
Mail flow between your on-premises deployment and your Exchange Online organization is secured and protected by Transport Layer Security (TLS). The TLS endpoint in your on-premises organization must be an Exchange 2010 SP2 Hub Transport or Edge Transport server running Exchange 2010 SP1 or SP2. Your on-premises organization and Exchange Online organization send messages directly to each other through a secure channel. To enable this mail flow, a dedicated hybrid Send connector is automatically created by the Manage Hybrid Configuration wizard. Only a Hub Transport server running on Exchange 2010 SP2 or Edge Transport source servers running on Exchange 2010 SP1 or Exchange 2010 SP2 can be selected for this Send connector. If youre running Exchange 2010 SP2 in your organization, any Hub Transport or Edge Transport server can act as the gateway to your Exchange Online organization. If youre running older versions of Exchange, you must deploy hybrid Hub Transport or Edge Transport servers to route messages between your two organizations. In a hybrid deployment, each organization treats the other one as an internal organization. There is practically no difference between a user hosted on your on-premises servers and an Exchange Online user when Exchange is processing messages. Anti-spam filters are also bypassed for messages between the two organizations.

Secured and Authenticated Mail Flow

Even though messages between the on-premises and Exchange Online organizations go through a logical tunnel, theyre still transferred over the Internet and therefore must be protected against malicious users. Exchange 2010 provides the following protection measures:

Channel privacy Unauthorized parties cant access any captured packets. Receiver authentication Senders are protected from unauthorized parties impersonating valid receivers. Sender authentication Receivers are protected from unauthorized parties impersonating valid senders.

Channel Privacy
To protect both the on-premises and cloud-based organizations, Exchange 2010 forces TLS using Secure Sockets Layer (SSL) certificates provided by a trusted third-party Certificate Authority (CA). Self-signed certificates are not supported for channel privacy in a hybrid deployment. All messages sent through the TLSprotected channel are encrypted. The sending and receiving servers examine the certificate configured on the other server. The subject name, or one of the subject alternative names (SANs), configured on the certificates must match the fully qualified domain name (FQDN) that an administrator has explicitly specified on the other server. For example, if the Exchange Online organization is configured to accept and secure messages sent from the mail.contoso.com FQDN, the sending on-premises hybrid servers must have an SSL certificate with mail.contoso.com in either the subject name or SAN. If this requirement isn't met, the connection is refused.

Receiver Authentication
In addition to the regular certificate checks performed during TLS, the Send connectors that participate in hybrid deployment mail flow also perform domain validation. Domain validation is an additional security feature that reduces the risk of malicious users impersonating a receiving server. When domain validation is enabled on a Send connector, the Transport server performs the following security checks on the outbound connection:

The communication channel is encrypted using TLS. The certificate of the receiving server is validated, and revocation list checks are performed. The Transport server verifies that the FQDN on the certificate of the receiving server matches the domain configured in the Send connector properties.

Sender Authentication

To prevent a malicious user from impersonating a valid sender, each message is authenticated to verify that it was submitted by the specified sender. Inside an Exchange organization, sender authentication is verified by using custom message headers added by Exchange servers. For messages that are sent between the on-premises and Exchange Online organizations, these header values are encrypted at the source and then decrypted and verified at the destination. While in transit, these headers cant be decrypted by any third party that might capture the message.

Mail To and From the Internet

Recipients in the on-premises and Exchange Online organizations typically have the same reply address, such as @contoso.com. Because they have the same reply address, all messages to recipients in both organizations must follow the same inbound route. All inbound messages can be delivered either to the on-premises organization or to the Exchange Online organization. Where you decide to route inbound messages depends on where the majority of your mailboxes are located, whether you have a Microsoft Forefront Online for Protection (FOPE), and other factors. Messages sent from recipients in the on-premises and Exchange Online organizations can either follow the same or different routes to the Internet. Messages sent from on-premises recipients are always sent directly to the Internet. Messages sent from Exchange Online recipients can either be sent directly to the Internet or routed through your on-premises organization first. You may want to route Exchange Online messages through your on-premises organization if you want to apply compliance policies to them first. There are many considerations that you need to think about when planning transport for your hybrid deployment, such as whether you use FOPE to protect your onpremises organization, whether you have an Edge Transport server configured, and how you want to route inbound and outbound Internet mail. For detailed information about these considerations and help on deciding which options are best for your organization, see Understanding Transport Options in Exchange 2003 Hybrid Deployments.

Transport Features
This section discusses how various Transport features are used in a hybrid deployment. The information here assumes that youre running Exchange 2010 for your onpremises deployment because some of the features described here dont apply to earlier versions of Exchange. To learn more, see the following topics:

Upgrade from Exchange 2007 Transport Upgrade from Exchange 2003 Transport Note: The features discussed in this section are only available in a hybrid deployment.

Transport Rules and Journaling

Transport Rules and Journaling rules arent synchronized between your on-premises deployment and your Exchange Online organization. Therefore, you must ensure that you keep any rules that you have implemented consistent in both organizations.

Delivery Reports
Users can track messages theyve sent and received in a hybrid deployment as long as delivery reports are enabled for the corresponding organizational relationships for both the on-premises and Exchange Online organizations. By default, this feature is enabled in a hybrid deployment. However, keep in mind that if you have older versions of Exchange in your on-premises deployment, the delivery reports will not show the final delivery to recipients hosted on the legacy servers, but rather that the message was transferred to the legacy Exchange system. This isnt a limitation of the hybrid deployment; its because of changes in the message tracking implementation in Exchange 2010. For more information, see the Message Tracking Across Versions section in Upgrade from Exchange 2007 Transport.

MailTips
MailTips are designed to work seamlessly in a hybrid deployment. If an on-premises user addresses a message to a recipient in your Exchange Online organization, your local Client Access servers contact the Client Access servers in the Exchange Online organization and requests MailTips data for the message. Upon this request, the Client Access servers in the Exchange Online organization processes the MailTips request, evaluates the message for any MailTips, and returns all applicable MailTips to your on-premises Client Access servers. The process is the same when a user in your Exchange Online organization addresses a message to an onpremises recipient. In a hybrid deployment, keep in mind the following differences regarding MailTips:

The External Recipients MailTip is evaluated only in the local organization. This is because the Exchange Online organization cant determine which recipients would be considered external for an on-premises user. Number of external recipients in a group MailTip is only evaluated for the local groups using the local Group Metrics data for the same reason. The Oversize Message MailTip is evaluated both locally and in the remote organization. Therefore, its important to make sure that the message size restrictions for your on-premises organization match those configured for your Exchange Online organization to avoid an inconsistent experience for your users. All objects in the remote organization are represented as mail-enabled objects in the local organization. For example, a mailbox in your Exchange Online organization is represented as a mail user in your on-premises organization. Because all objects can have Custom MailTips, you potentially can configure two different Custom MailTips for the same recipient. In this case, only the local Custom MailTip will be shown. On-premises users will see the Custom MailTip configured for the on-premises object, and cloud-based users will see the Custom MailTip configured for the Exchange Online object. Its also possible to have a mismatching configuration for moderated recipients or restricted recipients. For example, an on-premises mailbox may be restricted, but the corresponding mail user in your Exchange Online organization may not be restricted. In this scenario, the Restricted Recipient MailTip will be shown even for an Exchange Online user. The Moderated Recipient MailTip functions in a similar fashion. MailTips are configured to work in a hybrid deployment by default. However, its possible to customize the way MailTips are handled if you want different experiences

for your on-premises and Exchange Online users. For more information, see the MailTips Architecture section in Understanding MailTips and Use the Shell to configure MailTips for organizational relationships section in Configure Organizational Settings for MailTips.

Message Moderation
Hybrid deployment message moderation functionality relies on the following requirements:

Synchronization of moderation attributes of mail-enabled objects. At least one arbitration mailbox created in your on-premises organization. At least one arbitration mailbox created in your Exchange Online organization. Preservation of the headers and TNEF format between the two organizations. When you configure a hybrid deployment with Office 365, all the requirements above are met. You dont need to do anything additional for message moderation to work.

Edge Transport in a Hybrid Deployment

Mail flow in a hybrid deployment requires an Exchange 2010 SP2 server as the TLS endpoint for your on-premises deployment. This is typically an Exchange 2010 SP2 Hub Transport server in your on-premises organization. However, if you dont want to expose your internal Hub Transport server directly to the Internet, you can use an Exchange 2010 SP2 Edge Transport server as the TLS endpoint. If you use an Edge Transport server, that server will handle mail between your on-premises organization and the Exchange Online organization on behalf of the Hub Transport server. You can also elect to use an Edge Transport server for handling mail sent to and from Internet recipients for your on-premises organization. To learn more about Edge Transport servers in your hybrid deployment, see:

Understanding Edge Transport Servers in Exchange 2003 Hybrid Deployments If youre using Exchange 2007 Edge Transport servers in your organization, they must be upgraded to Exchange 2010 SP2 if you plan to use them in a hybrid deployment.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Mailbox
Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-11-17 Microsoft Exchange Server 2010 Mailbox servers host mailbox databases and provide e-mail storage and advanced scheduling services for Microsoft Outlook and Microsoft Office Outlook Web App users. In addition, Mailbox servers can also host a public folder database, which provides a foundation for workflow, document sharing, and other forms of collaboration. The following topics provide detailed information about the Mailbox features in Exchange 2010: Overview of the Mailbox Server Role Understanding Address Lists Understanding Calendar Repair Understanding E-Mail Address Policies Understanding the Exchange 2010 Store Understanding Exchange Search Understanding Hierarchical Address Books Understanding Mailbox Import and Export Requests Understanding Move Requests Understanding Offline Address Books Understanding Public Folders Understanding Quota Messages Understanding Recipients Understanding Recoverable Items 2010 Microsoft Corporation. All rights reserved.
2013 Microsoft. All rights reserved.

Overview of the Mailbox Server Role

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-05-09 In Microsoft Exchange Server 2010, the Mailbox server role is one of several server roles that you can install and configure on a server running Windows Server 2008. The Mailbox server role is the most common server role and is at the core of an Exchange organization. Servers on which the Mailbox server role is installed are called Mailbox servers. Mailbox servers perform the following functions:

Host mailbox databases Provide e-mail storage Host public folder databases Calculate e-mail address policies Generate address lists and offline address books (OABs) Conduct Multi-Mailbox Searches Provide high availability and site resiliency Provide content indexing Provide messaging records management (MRM) and retention policies Looking for management tasks related to Mailbox servers? See Managing Mailbox Servers. Contents Mailbox Server Interactions Coexisting with Other Server Roles Server Role Configuration Services and Port Executables Planning for Public Folders

Mailbox Server Interactions

The Mailbox server must interact directly with the following:

Active Directory Client Access server Hub Transport server Unified Messaging server Microsoft Outlook clients

The following process applies:

1. The Mailbox server uses LDAP to access recipient, server, and organization configuration information from Active Directory. 2. The store driver on the Hub Transport server places messages from the transport pipeline into the appropriate mailbox. The store driver on the Hub Transport server also adds messages from a sender's Outbox on the Mailbox server to the transport pipeline. To learn more about the store driver, see Understanding Moderated Transport. 3. The Client Access server sends requests from clients to the Mailbox server, and returns data from the Mailbox server to the clients. The Client Access server also accesses OAB files on the Mailbox server through NetBIOS file sharing. The types of data that the Client Access server sends between the client and the Mailbox server include messages, free/busy data, client profile settings, and OAB data. 4. The Unified Messaging server retrieves e-mail, voice mail messages, and calendar information from the Mailbox server for Outlook Voice Access. The Unified Messaging server also retrieves storage quota information from the Mailbox server. To learn more about Outlook Voice Access, see Understanding Outlook Voice Access. 5. Outlook clients inside your firewall access the Client Access server to send and retrieve messages. Outlook clients outside the firewall can access the Client Access server by using Outlook Anywhere (which uses RPC over HTTP). However, Outlook clients that are viewing or modifying public folders access the Client Access server by using RPC over TCP. To learn more about Outlook Anywhere, see Understanding Outlook Anywhere. 6. The administrator-only computer retrieves Active Directory topology information from the Microsoft Exchange Active Directory Topology service. It also retrieves e-mail address policy information and address list information. 7. The Client Access server uses LDAP or Name Service Provider Interface (NSPI) to contact the Active Directory server and retrieve users' Active Directory information. Return to top

Coexisting with Other Server Roles

The Client Access server role, Hub Transport server role, Mailbox server role, and Unified Messaging server role can coexist on the same computer in any combination. When considering what combination of server roles to deploy, you should base your decision on capacity and performance planning and on your security and availability requirements. For more information, see Mailbox Server Storage Design. Return to top

Server Role Configuration

To configure the Mailbox server role, use the Set-MailboxServer cmdlet in the Exchange Management Shell. To retrieve Mailbox server role settings, use the GetMailboxServer cmdlet. For more information, see Configure Mailbox Server Properties. Return to top

Services and Port Executables

When you install the Exchange 2010 Mailbox server role on a computer running Windows Server 2008, the services and port executables shown in the following table are installed. The Microsoft Search (Exchange Server) and Microsoft Exchange Monitoring services are set to start manually. All other services are set to start automatically.

Services
Service short name MSExchangeIS MSExchangeADTopology MSExchangeMailboxAssistants MSExchangeSearch MSExchangeServiceHost MSExchangeMonitoring MSExchangeSA MSExchangeMailSubmission msftesql-Exchange MSExchangeTranportLogSearch Return to top Service name Microsoft Exchange Information Store Microsoft Exchange Active Directory Topology Microsoft Exchange Mailbox Assistants Microsoft Exchange Search Indexer Microsoft Exchange Service Host Microsoft Exchange Monitoring Microsoft Exchange System Attendant Microsoft Exchange Mail Submission Microsoft Search (Exchange Server) Microsoft Exchange Transport Log Search Associated executable Store.exe MSExchangeADTopologyService.exe MSExchangeMailboxAssistants.exe Microsoft.Exchange.Search.ExSearch.exe Microsoft.Exchange.ServiceHost.exe Microsoft.Exchange.Monitoring.exe Mad.exe MSExchangeMailSubmission.exe Msftesql.exe MSExchangeTransportLogSearch.exe Port name MSExchangeISPorts MSExchangeADTopologyPorts MSExchangeMailboxAssistantsPorts MSExchangeSearchPorts MSExchangeServiceHostPorts MSExchangeMonitoringPorts MSExchangeSAPorts MSExchangeMailSubmissionPorts msftesql-ExchangePorts MSExchangeTransportLogSearchPorts

Planning for Public Folders

Before you deploy public folders, it's important to familiarize yourself with the functionality that public folders provide to make sure that the public folders meet the needs of your organization.

Exchange public folders are intended to serve as a repository for information that's shared among many users. You should use public folders when your business requires data replication to multiple servers. Access to public folders is integrated with regular mailbox access through the MAPI protocol. For more information about public folders, see Understanding Public Folders and Managing Public Folders. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Address Lists

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-12-01 An address list is a collection of recipient and other Active Directory objects. Each address list can contain one or more types of objects (for example, users, contacts, groups, public folders, conferencing, and other resources). You can use address lists to organize recipients and resources, making it easier to find the recipients and resources you want. Address lists are updated dynamically. Therefore, when new recipients are added to your organization, they're automatically added to the appropriate address lists. As shown in the following figure, client applications, such as Microsoft Outlook, display the available address lists that Exchange provides.

Address lists reside in Active Directory. Therefore, mobile users who are disconnected from the network are also disconnected from these server-side address lists. However, you can create offline address books (OABs) for users who are disconnected from the network. These OABs can be downloaded to a user's hard disk. Frequently, to conserve resources, OABs are subsets of the information in the actual address lists that reside on your servers. For more information, see Understanding Offline Address Books. Looking for management tasks related to managing Mailbox servers? See Managing Mailbox Servers. Contents Changes to Address Lists in Exchange 2010 SP2 Default Address Lists Custom Address Lists Best Practices for Creating Address Lists

Changes to Address Lists in Exchange 2010 SP2

Global address list (GAL) segmentation (also known as GAL segregation) is the process whereby you segment users into specific groups to provide customized views of your organizations GAL. In Exchange Server 2007 and earlier, segmenting the GAL was complicated, requiring you to use either a Query Base DN which acted as a root for directory searches) or access control lists (ACLs) to allow or deny access to each address list. To simplify the process, Exchange 2010 Service Pack 2 (SP2) introduces address book policies (ABPs). When creating an ABP, you assign a GAL, an offline address book (OAB), a room list, and one or more address lists to the policy. You can then assign the ABP to mailbox users, providing them with access to a customized GAL in Outlook and Outlook Web App. The goal is to provide a simpler mechanism to accomplish GAL segmentation for on-premises organizations that require multiple GALs. To learn more about ABPs, see Understanding Address Book Policies.

Default Address Lists

When users want to use their client application to find recipient information, they can select from available address lists. Several address lists, such as the global address list (GAL), are created by default. Exchange contains the following default address lists, which are then automatically populated with new users, contacts, groups, or rooms as they're added to your organization:

All Contacts This address list contains all mail-enabled contacts in your organization. Mail-enabled contacts are those recipients who have an external e-mail address. If you want mail-enabled contact information to be available to all users in your organization, you must include the contact in the GAL. To learn more about mail contacts, see Understanding Recipients. All Groups This address list contains all mail-enabled groups in your organization. Mail-enabled groups are groups of recipients that are created to expedite the mass sending of e-mail messages and other information. When an e-mail message is sent to a mail-enabled group, all members of that list receive a copy of the message. To learn more about mail-enabled groups, see Understanding Recipients. All Rooms This address list contains all resources that have been designated as a room in your organization. Rooms are resources in your organization that can be scheduled by sending a meeting request from a client application. The user account that's associated with a room is disabled. For instructions about how to add resource mailboxes to an address list, see Add Resource Mailboxes to an Address List. To learn more about resource mailboxes, see Understanding

Recipients. All Users This address list contains all mail-enabled users in your organization. A mail-enabled user represents a user outside your Exchange organization. Each mail-enabled user has an external e-mail address. All messages sent to mail-enabled users are routed to this external e-mail address. A mail-enabled user is similar to a mail contact, except that a mail-enabled user has Active Directory logon credentials and can access resources. To learn more about mail-enabled users, see Understanding Recipients. Default Global Address List This address list contains all mail-enabled users, contacts, groups, or rooms in the organization. During setup, Exchange creates various default address lists. The most familiar address list is the GAL. By default, the GAL contains all recipients in an Exchange organization. In other words, any mailbox-enabled or mail-enabled object in an Active Directory forest that has Exchange installed is listed in the GAL. For ease of use, the GAL is organized by name, not by e-mail address. For more information, see Managing Address Lists. Public Folders This address list contains all public folders in your organization. Access permissions determine who can view and use the folders. Public folders are stored on computers running Exchange. For more information about public folders, see Managing Public Folders.

Custom Address Lists

An Exchange organization can contain thousands of recipients. If you compile all your recipients in the default address lists, those lists could become quite large. To prevent this, you can create custom address lists to help users in your organization find what they are looking for more easily. For example, consider a company that has two large divisions and one Exchange organization. One division, named Fourth Coffee, imports and sells coffee beans. The other division, Contoso, Ltd, underwrites insurance policies. For most day-to-day activities, the employees at Fourth Coffee don't communicate with the employees at Contoso, Ltd. Therefore, to make it easier for employees to find recipients who exist only in their division, you can create two new custom address listsone for Fourth Coffee and one for Contoso, Ltd. When searching for recipients in their division, these custom address lists allow employees to select only the address list that's specific to their division. However, if an employee is unsure about the division in which the recipient exists, the employee can search within the GAL, which contains all recipients in both divisions. You can also create subcategories of address lists called hierarchical address lists. For example, you can create an address list that contains all recipients in Manchester and another that contains all recipients in Stuttgart.

Best Practices for Creating Address Lists

Although address lists are useful tools for users, poorly planned address lists can cause frustration. To make sure that your address lists are practical for users, consider the following best practices:

Avoid creating so many address lists that users won't be sure which list to search for recipients. Name your address lists in such a way that, when users glance at them, they will know immediately which recipient types are contained in the list. If you have difficulty naming your address lists, create fewer lists and remind users that they can find anyone in your organization by using the GAL. For detailed instructions about creating an address list, see Create an Address List.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Address Book Policies

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2013-01-28 Global address list (GAL) segmentation (also known as GAL segregation) is the process whereby administrators can segment users into specific groups to provide customized views of their organizations GAL. In Microsoft Exchange Server 2007 and earlier versions, segmenting the GAL was complicated and required that you use either a Query Base DN (which acted as a root for directory searches) or access control lists (ACLs) to allow or deny access to each address list. To learn more about how to configure GAL segmentation in Exchange 2007, see Configuring Virtual Organizations and Address List Segregation in Exchange 2007. To simplify the process, Microsoft Exchange Server 2010 Service Pack 2 (SP2) introduces address book policies (ABPs). When creating an ABP, you assign a GAL, an offline address book (OAB), a room list, and one or more address lists to the policy. You can then assign the ABP to mailbox users, providing them with access to a customized GAL in Outlook and Outlook Web App. The goal is to provide a simpler mechanism to accomplish GAL segmentation for on-premises organizations that require multiple GALs. Note: ABPs are intended to optimize the GAL for each group of users, not make it impossible for them to see each other or to resolve other users in your organization. ABPs create only a virtual separation of users, not a legal separation. Important: ABPs aren't available in Office 365. As a result, if youre in a hybrid deployment, the entire address book will be visible to your users with cloud-based mailboxes.

How ABPs Work

ABPs contain the following lists:

One GAL One OAB One room list (for booking purposes) One or more address lists In the following figure, Address Book Policy A consists of a subset of the various address objects that exist in the organization (shown in the bottom half of the figure). The resulting scope of an ABP is equal to that of the GAL contained in the policy, in this case GAL1. When the ABP is created and assigned to a user, the address objects in the ABP become the scope of the objects the user is able to view.

You can use the following methods to assign ABPs to individual mailbox users:

New or existing mailbox? New Existing

Shell New-Mailbox cmdlet with the AddressBookPolicy parameter Set-Mailbox cmdlet with the AddressBookPolicy parameter

Exchange Management Console Mailbox Settings tab in the New Mailbox wizard Mailbox Settings tab in the mailboxs property page

ABPs take effect when a user's client application connects to the Microsoft Exchange Address Book service on the Client Access server. If you change the ABP, the updated ABP doesn't take effect until the user restarts Outlook Outlook Web Access, or until you restart the Microsoft Exchange Address Book service. To learn more, see Understanding the Address Book Service.

Entourage, Outlook for Mac, and ABPs

ABPs wont function for Entourage users or Outlook for Mac users who are connected to their corporate network. When inside the corporate network, Entourage and Outlook for Mac clients connect directly to the global catalog server and query Active Directory directly instead of using the Microsoft Exchange Address Book service. However, Outlook for Mac 2011 clients that connect from the Internet can use an OAB or Exchange Web Services (EWS). As a result, these clients can view the GAL based on the assigned ABP. To learn more about administering Outlook for Mac 2011, see Planning for Outlook for Mac 2011

Deploying ABPs
This section provides information about deploying ABPs in your organization, including best practices, scenarios, and general steps. To review all ABP management tasks, see Managing Address Book Policies.

Considerations and Best Practices

Consider the following when setting up ABPs in your organization:

For ABPs to work correctly, the user mailbox to which you apply the ABP must be on a Microsoft Exchange Server 2010 SP2 server. Dont run the Client Access server role on the global catalog server. Doing so results in Active Directory being used for Name Service Provider Interface NSPI instead of the Microsoft Exchange Address Book service. You can't use hierarchical address books (HABs) and ABPs at the same time. To learn more about HABs, see Understanding Hierarchical Address Books. Any user assigned an ABP should exist in their own GAL. If you allow client applications to access Active Directory directly through LDAP, they will bypass the logic built into ABPs. Because Outlook 2011 and Entourage 2008 use direct LDAP queries to access, Active Directory those client applications wont function properly with ABPs if a domain controller or global catalog server is specified or provided to them by the Autodiscover service. Outlook 2011 can use EWS or a local OAB to access directory information. However, if Outlook 2011 can directly access an LDAP service, it will try to do so. The GAL used in an ABP must, at a minimum, contain all of the address lists, including the room address list, defined and specified in an ABP. Dont create a GAL that contains fewer objects than any of the address lists in the same ABP. We recommend creating distribution groups that don't cross virtual organization boundaries. Creating distribution groups that contain members of multiple virtual organizations results in the following issues: If group members request delivery or read receipts when sending mail to the distribution group, theyll be able to see the e-mail addresses of the group members in other virtual organizations If an encrypted message is sent to the distribution group and some group members dont have valid digital IDs, the sender will receive a warning message that includes the total number of members who dont have valid IDs and a list of their e-mail addresses. However, if some of those members without valid digital IDs are in a different organization than the sender, the warning message will include the correct count but wont include the e-mail addresses of the members in the other organization. As a result, the total count wont match the list of member addresses. For example, lets say a distribution group contains five members total from two organizations, Agency A and Agency B. Three group members are from Agency A, and one of those members has as invalid digital ID. The other two members are from Agency B, and both of them have invalid digital IDs. If a member from Agency A sends an encrypted message to the distribution group, that member will receive a warning message stating that there are a total of three recipients without valid digital IDs. However, only the e-mail address for the recipient from Agency A will be listed in the warning message. ABP's dont apply to the Get-Group cmdlets. Therefore, any user or process that is able to run Get-Group will see all members of any group they have access to. We recommend that you modify the group management settings of the Exchange Control Panel ECP so users cant use ECP to manage groups. To prevent users from using ECP to manage groups, exclude the users from the MyDistributionGroupMembership RBAC role. For details see MyDistributionGroupMembership Role and Turn Off User's Ability to Create Distribution Groups. If you allow users to use Outlook or Outlook Web App to manage groups, the group owners must have full visibility to the group membership list. All ABPs must contain a room address list. However, if your organization doesn't use room address lists, you can create a default empty room address list. Deploying ABPs doesn't prevent users in one virtual organization from sending e-mail to users in another virtual organization. If you want to prevent users from sending e-mail across organizations, we recommend that you create a transport rule. For example, to create a transport rule that prevents Contoso users from receiving messages from Fabrikam users, but still allows Fabrikams senior leadership team to send messages to Contoso users, run the following Shell command:

New-TransportRule -Name "StopFabrikamtoContosoMail" -FromMemberOf "AllFabrikamEmployees" -SentToMemberOf "AllContosoEmployees" -DeleteMessage

To learn more, see Create a Transport Rule. If you want to enforce the ABP in the Lync client, you can set the msRTCSIP-GroupingID attribute on specific user objects. For details, see PartitionByOU Replaced with msRTCSIP-GroupingID topic.

Deployment Scenarios
The following three scenarios describe possible deployment solutions for three different organization types. Although there are many more scenarios, the most common ones are covered here. The address lists and GALs in these scenarios were created based on filters, such as Custom Attributes, that grouped the objects logically.

Scenario 1: Two Separate Companies - One Exchange Organization

This scenario is applicable to companies that have separate agencies, divisions, or departments that are:

Within the same Exchange organization. Dont share employees. Dont share a common reporting chain. In addition, the agencies, divisions, or departments don't have any special security or privacy concerns. In this scenario, two ABPs are created with the following settings:

Employees who view the GAL or distribution group membership can see only recipients within their company. There are no distribution groups that span across both companies.

The following table lists the address lists, GALs, room lists, and OABs that are included in the ABPs for Contoso and Humongous Insurance. The ABP components were created by using the CustomAttribute15 parameter to group the objects. Because the two companies are separate without any interaction between them, they dont share any address lists.

ABP component Address lists

Contoso AL_CON_Groups AL_CON_Users_DGs AL_CON_Contacts GAL_CON AL_CON_Rooms OAB_CON

Humongous Insurance AL_HI_Groups AL_HI_Users_DGs AL_HI_Contacts GAL_HI AL_HI_Rooms OAB_HI

GAL Room list OAB

Scenario 2: Two Companies Sharing a CEO

This scenario is applicable to companies that are:

Within the same Exchange organization. Share the same CEO. Dont share employees. In this scenario, three ABPs are created with the following settings:

Employees who view the GAL or distribution group membership can see only recipients within their company. In each company, there is a distribution group named SeniorLeaders, which includes the senior leaders of that company and the shared CEO. Employees who view the CEO's group membership can see only groups within their company. Three ABPs are created: Fabrikam, Tailspin Toys, and CEO.

ABP component Address lists

Fabrikam AL_FAB_Users_DGs AL_FAB_Contacts

Tailspin Toys AL_TAIL_Users_DGs AL_TAIL_Contacts

CEO AL_FAB_Users_DGs AL_FAB_Contacts AL_TAIL_Users_DGs AL_TAIL_Contacts Default GAL Default All Rooms Default OAB

GAL Room list OAB

GAL_FAB AL_FAB_Rooms OAB_FAB

GAL_TAIL AL_TAIL_Rooms OAB_TAIL

When the CEO is added to the distribution groups in each company and falls within the scope of each company's ABP, the CEO becomes visible to each company. The CEO is visible in both the Fabrikam and Tailspin Toys GALs and can create distribution groups that span both companies. However members of the distribution group can view only members that are within their own company.

Scenario 3: Education
This scenario is applicable to schools or universities where a division of classrooms is necessary to ensure the privacy of the students. In this scenario, ABPs are created with the following settings:

Students can view only other students in their classroom, their teacher, and the principal. Teachers can view only students in their classroom, all teachers, and the principal. Distribution groups are created for each classrooms parents and the faculty.

Students_ClassA Address Lists AL_ClassA AL_Principal

Teachers_ClassA AL_ClassA AL_AllTeachers AL_AllGroups AL_Principal

Principal AL_ClassA AL_ClassB AL_AllTeachers AL_AllStudents AL_AllGroups GAL_Everyone Default All Rooms Default OAB

Global address list Room address list Offline address book

GAL_StudentsClassA AL_BlankRoom OAB_StudentsClassA

GAL_TeachersClassA AL_BlankRoom OAB_TeachersClassA

General Deployment Steps

This section provides the general steps for deploying ABPs in your organization, including how to migrate from Exchange 2007 address list segmentation.

Migrating from Address List Segmentation to ABPs

If youre currently using Exchange 2007 address list segmentation per the instructions in the white paper Configuring Virtual Organizations and Address List Segregation in Exchange 2007) and you want to migrate to ABPs, follow the steps outlined in Migrate to Exchange 2010 Address Book Policies from Exchange 2007 Address List Segregation. This procedure requires some downtime for your organization so be sure plan accordingly.

New Deployment of ABPs

If you arent using Exchange 2007 address list segmentation, follow the steps listed in this section to deploy ABPs in your organization. The following steps apply to Scenario 2: Two Companies Sharing a CEO. In this scenario, Fabrikam and Tailspin Toys are separate companies that share a CEO and senior leadership team. This scenario requires three ABPs:

ABP_FAB ABP_TAIL ABP_CEO

Step 1: Divide your virtual organizations

You'll need to develop a way to divide your organization into virtual organizations. When making this division, we recommend using the Custom Attribute properties on the mailboxes, contacts, and groups instead of the precanned conditional attributes (such as Company, Department, or State/Province). Using Custom Attributes instead of precanned attributes includes the following benefits:

Not all recipient types have precanned conditional attributes in Active Directory. For example, the Active Directory objects Distribution Group and Dynamic Distribution Group dont support the Company, Department, or State/Province attributes. Not all precanned conditional attributes are exposed in cmdlets for some recipients. For example, the Company, Department, and StateOrProvince parameters arent available in the cmdlets for mail users, contacts, distribution groups, and mail-enabled public folders. Multiple cmdlets are required to segment recipients when you use precanned conditional attributes. For example, to set the Company, Department, or StateOrProvince parameters for a user mailbox, you must run the Set-User cmdlet after you run the New-Mailbox or Set-Mailbox cmdlets. However, the CustomAttribute parameters are exposed in the Set-* cmdlets for each recipient type, so theres no need to also run the Set-User cmdlet. Custom Attribute properties are explicitly reserved to customize an organization and are controlled entirely by organization administrators. To learn more about custom attributes, see Understanding Custom Attributes. Another best practice to consider when dividing your organization is to use company identifiers in the names of distribution groups and dynamic distribution groups. One method for doing this is to use group naming policies. These policies allow you to specify that a prefix, a suffix, or both be applied to distribution group names. This is helpful when dividing your organization because you can use these policies to specify a suffix or prefix based on user attributes such as the creator of the distribution group's Company, State/Province, Department, and Custom Attribute properties. This is especially important if you allow users to create their own distribution groups. For more information, see Create a Distribution Group Naming Policy. Note: Because group naming policies don't apply to dynamic distribution groups, you must manually apply a naming policy.

Step 2: Create the address lists, room list, GALs, and OABs
When you create the address lists and GALs, dont use the IncludedRecipient and ConditionalX parameters, such as ConditionalCompany and ConditionalCustomAttribute5. Instead, we recommend that you use recipient filters. To learn more about recipient filters, see Creating Filters in Recipient Commands. Note: All procedure in this section use Shell commands because you cant use the EMC to create recipient filters. Create the address lists When you create the ABP, you include multiple address lists based on how you want your users to view the lists in Outlook or Outlook Web App. This scenario requires four address lists:

AL_FAB_Users_DGs AL_FAB_Contacts AL_TAIL_Users_DGs AL_TAIL_Contacts This example creates the address list AL_TAIL_Users_DGs. The address list contains all users and distribution groups where CustomAttribute15 equals TAIL.

New-AddressList -Name "AL_TAIL_Users_DGs" -RecipientFilter {((RecipientType -eq 'UserMailbox') -or (RecipientType -eq "MailUniversalDistributio

The above command would then be run to create the remaining address lists: AL_FAB_Users_DGs, AL_FAB_Contacts, and AL_TAIL_Contacts. For detailed syntax and parameter information, see New-AddressList. To learn more about creating address lists by using recipient filters, see Create an Address List By Using Recipient Filters. Create the room lists This scenario requires three room lists:

AL_FAB_Rooms AL_TAIL_Rooms Default All Rooms (created by default) ABPs must contain a room list. If your organization doesn't have resource mailboxes (such as room or equipment mailboxes), we recommend that you create a blank room list. The following example creates the blank room list AL_BlankRoom.

New-AddressList -Name AL_BlankRoom -RecipientFilter ((Alias -ne $null) -and ((RecipientDisplayType -eq 'ConferenceRoomMailbox') -or (RecipientD

However, in this scenario, Fabrikam and Tailspin Toys both have room mailboxes. This example creates the room list for Tailspin Toys by using a recipient filter where CustomAttribute15 equals TAIL.

New-AddressList -Name AL_TAIL_Rooms -RecipientFilter {(Alias -ne $null) -and (CustomAttribute15 -eq "TAIL")-and (RecipientDisplayType -eq 'Conf

The above command would then be run to create the room list for Fabrikam (AL_FAB_Rooms). For detailed syntax and parameter information, see New-AddressList. Create the GALs This scenario requires three GALs:

GAL_FAB GAL_TAIL Default GAL (created by default) The GAL used in an ABP must be a superset of the address lists. Dont create a GAL with fewer objects than exists in any or all of the address lists in the ABP. This example creates the GAL for Tailspin Toys. It includes all the recipients that exist in the address lists and room list.

New-GlobalAddressList -Name "GAL_TAIL" -RecipientFilter {(CustomAttribute15 -eq "TAIL")}

The above command would then be run to create the GAL for Fabrikam (GAL_FAB). For detailed syntax and parameter information, see New-GlobalAddressList. Create the OABs This scenario requires three GALs:

OAB_FAB OAB_TAIL Default OAB (created by default) When using the New-OfflineAddressBook or Set-OfflineAddressBook to create the OAB, include the appropriate address lists or GAL in the AddressLists parameter to make sure no entry is unexpectedly missed. For example, if you want to customize the set of lists a user will see when viewing the OAB, or if you simply want to reduce the OABs download size, you can use the AddressLists parameter to specify the address lists available to the OAB. However, if you want users to see the full set of GAL entries in OAB, make sure you include the GAL in the AddressLists parameter. This example creates the OAB for Tailspin Toys. The entire GAL (GAL_TAIL) is included in the OAB..

New-OfflineAddressBook -Name "OAB_TAIL" -AddressLists "GAL_TAIL"

The above command would then be run to create the OAB for Fabrikam (OAB_FAB). For detailed syntax and parameter information, see New-OfflineAddressBook.

Step 3: Create the ABPs

After all the required lists are created, you can create the ABPs. This example creates the ABP for Tailspin Toys.

New-AddressBookPolicy -Name "ABP_TAIL" -AddressLists "AL_TAIL_Users_DGs","AL_TAIL_Contacts" -OfflineAddressBook "\OAB_TAIL" -GlobalAddressList

The above command would then be run to create the ABPs for Fabrikam ABP_FAB and the organizations CEO ABP_CEO. For detailed syntax and parameter information, see New-AddressBookPolicy.

Step 4: Assign the ABPs to mailboxes

Assigning the ABPs to users is the last step in the process. ABPs take effect when a user's application connects to the Microsoft Exchange Address Book service on the Client Access server. Users who are already connected to Outlook or Outlook Web App when the ABP is applied to their account will have to close and then restart the client application before they can see their new address lists and GAL. This example assigns the address book policy ABP_TAIL to all mailboxes where CustomAttribute15 equals TAIL.

Get-Mailbox -resultsize unlimited | where {$_.CustomAttribute15 -eq "TAIL"}| Set-Mailbox -AddressBookPolicy "ABP_TAIL"

For more details, see Assign an Address Book Policy to a Mail User.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Migrate to Exchange 2010 Address Book Policies from Exchange 2007 Address List Segregation
Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 The instructions in this topic will walk you through the steps required to migrate from Exchange 2007 ACL-based global address list (GAL) segmentation (also known as GAL segregation) to Exchange 2010 Service Pack 2 (SP2) address book policies (ABPs). Important: Several procedures in this topic will impact users. As a result, scheduled downtime is often required.

Prerequisites
Although not a specific prerequisite, its highly recommended that you review the considerations and best practices in Understanding Address Book Policies before performing the procedures in this topic. The procedures in this topic assume that you followed the steps in the white paper Configuring Virtual Organizations and Address List Segregation in Exchange 2007 to configure your Exchange 2007 organization. If you followed the steps in the white paper listed above to implement GAL segmentation in your Exchange 2010 organization, you are officially in an unsupported state. To successfully perform the procedures in this topic, you must first return your organization to a supported state. Most of the code and Shell examples in this document use Contoso as the Active Directory domain name and the Exchange organization name, and Fabrikam, and Tailspin Toys as the sub-organization names. Be sure to change the name of the Exchange organization, domain, and sub-organizations to match your configuration. You will need the scripts that you used to segment the virtual organizations in Exchange 2007.

Setting Up the Scenario

In this scenario, Tailspin Toys and Fabrikam are subsidiaries of the parent company Contoso.

Step1: Prepare to install Exchange 2010 SP2 in an existing Exchange 2007 organization that has configured GAL segmentation (downtime required)
If your organization is using Exchange 2007 GAL segmentation, installing Exchange 2010 will fail because using GAL segmentation required you to remove all the default settings and permissions from the default GAL.

1. On a domain controller in the Exchange 2007 organization, run the following command at the command prompt to allow access to the default GAL.

DSACLS "CN=Default Global Address List,CN=All Global Address Lists,CN=Address Lists Container,CN=CONTOSO,CN=Microsoft Exchange,CN=Services,CN=C

2. On a domain controller that has Windows PowerShell installed or on an Exchange server using the Exchange Management Shell, run the following commands to reconfigure the default settings on the GAL. Note: After you complete this step, Outlook 2007 users will be able to see the default GAL. However, Outlook Web App users wont be able to see the default GAL because Outlook Web App uses the QueryBaseDN attribute to query the GAL.

$container = "CN=Default Global Address List,CN=All Global Address Lists,CN=Address Lists Container,CN=CONTOSO,CN=Microsoft Exchange,CN=Service

You will receive the following warning and output:

WARNING: Identity -------\Default \Default \Default \Default

Appropriate ACE is already present on object "CN=Default Global Address List,CN=All Global Address Lists,CN=Address Lists Container,CN User Deny Inherited Rights ------- --------- -----Global A... NT AUTHORITY\Auth... False False Open-Address-Book Global A... NT AUTHORITY\Auth... False False ReadProperty Global A... NT AUTHORITY\Auth... False False ListObject, Generi... Global A... NT AUTHORITY\Auth... False False ListChildren

Step 2: Install the first Exchange 2010 server

For detailed instructions, see Upgrade from Exchange 2007 Client Access

Step 3: Secure the default GAL

After you install Exchange 2010 SP2, you can remove the address lists that are created during installation and then secure the default GAL again. After you complete this step, you can continue to install additional Exchange 2010 SP2 servers in your organization. For more information, see Understanding Upgrade from Exchange 2007 to Exchange 2010.

1. (Optional) On an Exchange 2010 server, use the Shell to remove the newly created address lists.

Remove-AddressList Remove-AddressList Remove-AddressList Remove-AddressList

"All Contacts" "All Groups" "All Users" "Public Folders"

For more detail, see Remove an Address List. 2. On an Exchange 2010 server, use the Shell to secure the GAL based on the instructions in the white paper Configuring Virtual Organizations and Address List Segregation in Exchange 2007.

Get-GlobalAddressList "Default Global Address List" | Add-ADPermission -User "Authenticated Users" -AccessRights GenericRead -ExtendedRights Op

3. To verify that the commands were successful, run the following commands.

$galContainer = "CN=All Global Address Lists,CN=Address Lists Container,CN=CONTOSO,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contos Get-ADPermission $galContainer -user "authenticated users"

The output of this command should resemble the following:

Identity -------All Global All Global All Global All Global

Addres... Addres... Addres... Addres...

User ---NT AUTHORITY\Auth... NT AUTHORITY\Auth... NT AUTHORITY\Auth... NT AUTHORITY\Auth...

Deny ---False False False True

Inherited --------False False True True

Rights -----GenericRead Open-Address-Book ListChildren ReadProperty

Step 4: Switchover to Exchange 2010 servers (downtime required)

Before moving any mailboxes to Exchange 2010 SP2 servers, you must switchover external URL names. This requires configuring Outlook Anywhere, Outlook Web App, Exchange Web Services (EWS), Exchange Control Panel (ECP), AutoDiscover, and offline address books (OABs) to use Exchange 2010 servers instead of Exchange 2007 servers. There are many steps in this process, and you should refer to the information in Exchange 2007 - Planning Roadmap for Upgrade and Coexistence for more detail. Note: The following steps outline only the key procedures in the overall process and explain what each of them accomplishes. You may need to run some of these commands on each server in your organization some only once, and most will result in some period of downtime. Therefore, its strongly recommended that you spend adequate time testing your entire switchover process to ensure minimal impact to your clients. 1. Use the Shell to move all OAB generation to an Exchange 2010 Mailbox server. Moving the OAB generation to Exchange 2010 SP2 servers allows OABs to use GALs and not just address lists as sources for the OAB content.

Get-OfflineAddressBook | Move-OfflineAddressBook -Server "MBX01_Ex2010SP2"

For more detail, see Move the Offline Address Book Generation to Another Server. 2. Set the virtual directory for the OAB to include an Exchange 2010 virtual organization. This will distribute copies of the OABs to the Exchange 2010 servers. This example ensures both the Exchange 2007 and Exchange 2010 servers have copies of all OABs.

Get-OfflineAddressBook | Set-OfflineAddressBook -virtualdirectories "CAS1_Ex2007\OAB (Default Web Site)","CAS1_Ex2010SP2\OAB (Default Web Site)

For more detail, see Configure Offline Address Book Distribution Properties. 3. Before any mailboxes can be moved to Exchange 2010, you must route all incoming Outlook Anywhere traffic through Exchange 2010. This example enables Outlook Anywhere on an Exchange 2010 server and disables it on an Exchange 2007 server.

Enable-OutlookAnywhere -Server:CAS1_Ex2010SP2 -ExternalHostname:mail.contoso.com -ClientAuthenticationMethod:Basic

Disable-OutlookAnywhere

-Server:CAS1_Ex2007

For more detail, see the following topics: Enable Outlook Anywhere Disable Outlook Anywhere 4. To allow AutoDiscover to properly return URLs from Exchange 2010 servers, you must configure Outlook Web App, Exchange ActiveSync, EWS, and ECP on all Exchange 2010 servers to have valid external URL properties for the virtual directories. The following examples assume that mail.contoso.com is the external name used to access the Exchange 2010 servers.

Set-ActiveSyncVirtualDirectory -Identity 'CAS1_Ex2010SP2\Microsoft-Server-ActiveSync*' -ExternalURL https://mail.contoso.com/Microsoft-Server-A Set-WebServicesVirtualDirectory -Identity 'CAS1_Ex2010SP2\EWS*' -ExternalUrl https://mail.contoso.com/EWS/exchange.asmx Set-OWAVirtualDirectory -Identity 'CAS1_Ex2010SP2\OWA*' -ExternalURL https://mail.contoso.com/OWA Set-EcpVirtualDirectory -Identity 'CAS1_Ex2010SP2\ECP*' -ExternalURL https://mail.contoso.com/ECP

For more detail about how to configure the above settings, see the following topics: Configure Exchange ActiveSync Autodiscover Settings Configure Exchange Services for the Autodiscover Service View or Configure Outlook Web App Virtual Directories Configure ECP Virtual Directory Properties 5. To allow Exchange 2010 to redirect Outlook Web App and EWS requests back to Exchange 2007 for those users with mailboxes on Exchange 2007 servers, you need to configure the Outlook Web App and EWS external URL for 2007 to use legacy.contoso.com. This namespace is the external name used to access the Exchange 2007 servers.

Set-WebServicesVirtualDirectory -Identity 'CAS1_Ex2007\EWS*' -ExternalUrl https://legacy.contoso.com/EWS/exchange.asmx Set-OWAVirtualDirectory -Identity 'CAS1_Ex2007\OWA*' -ExternalURL https://legacy.contoso.com/OWA

6. To allow Exchange 2010 to proxy all incoming Exchange ActiveSync connections to Exchange 2007, clear the 2007 external URL for Exchange ActiveSync.

Set-ActiveSyncVirtualDirectory -Identity 'CAS1_Ex2007\Microsoft-Server-ActiveSync*' -ExternalURL:$null

7. The final step in the process is to change the public DNS so that mail.contoso.com (in the example we provided) and autodiscover.contoso.com resolve to Exchange 2010, and the legacy.contoso.com DNS record resolves to Exchange 2007. All client connections will go through Exchange 2010, and then Exchange 2010 will either redirect (in the case of Outlook Web App), proxy (in the case of Exchange ActiveSync), or provide version-specific URLs (in the case of EWS) to clients via AutoDiscover.

Step 5: Create ABPs that mirror the Exchange 2007 address list segmentation ACLs
The next step is to figure out what address lists, GALs, and OABs the virtual organizations have access to using GAL segmentation, and then create an ABP for each virtual organization that mirrors them.

1. If you used the steps in Configuring Virtual Organizations and Address List Segregation in Exchange 2007 to set up your Exchange 2007 organization, you created scripts that segmented your virtual organizations. View those scripts that you used to create the virtual organizations in Exchange 2007 to determine the GAL, address lists, and OAB for each virtual organization. For each virtual organization, you should find one GAL, at least one address list, and one OAB. Note: ABPs must have a room list. If you dont use room lists in your organization, create a blank room address list and then use that address list when configuring the ABP or set the room list property in the ABP to use the same address list you specify for the GAL. For example, when viewing the script used to segment the child company Tailspin Toys, the following information is located: Tailspin Toys users are all contained in a security group called Tailspin_SG. The security group Tailspin_SG grants users read/open access to the following:

Address Lists AL_TailspinUsers AL_TailspinGroups AL_TailspingContacts

GAL GAL_Tailspin

OAB OAB_Tailspin

Tailspin Toys doesnt have a room address list. 2. Create an ABP that matches the Tailspin Toys organization. 3. For example, if you use the Exchange Management Console to create the ABP in, input the following information in the New Address Book Policy wizard:

If you use the Shell to create the ABP, run the following command.

New-AddressBookPolicy -Name 'ABP_Tailspin' -GlobalAddressList '\GAL_Tailspin' -OfflineAddressBook '\OAB_Tailspin' -AllRoomList '\RAL_BLANKROOMS

For more detail, see Create an Address Book Policy. 4. Follow the above instructions for each of your virtual organizations. For example, Fabrikam.

Step 6: Move mailboxes from Exchange 2007 servers to Exchange 2010 servers (downtime required)
In moving mailboxes to the Exchange 2010 servers, you will be switching over from using the ACLs to using ABPs. Note: We recommend that you create a script that performs this procedure in one step. 1. Move the mailboxes using the MoveRequest cmdlets. For more information, see Create a Local Move Request. 2. Assign the ABP to moved mailboxes. For more information, see Assign an Address Book Policy to a Mailbox User (EPW). 3. Clear the QueryBaseDN from the user object. This can be done directly via the Adsiedit.msc console or by using a multi-step process from the Shell. This example shows how to clear the QueryBaseDN by using the Shell.

$user = ([ADSI]"LDAP://CN=Bob,CN=Users,DC=Contoso,DC=com").psbase $user.Properties["msExchQueryBaseDN"].Value=$null $user.CommitChanges()

4. Remove the OAB setting from the mailbox. This example removes the OAB from Johns mailbox:

Set-Mailbox -Identity John -OfflineAddressBook $null

After the mailboxes are moved and all of the other settings have been configured, users using Outlook will get the following error and they will be required to close and restart Outlook: The Microsoft Exchange Administrator has made a change that requires you to quit and restart Outlook.

Step 7: Whats next?

So, after youve moved all of your mailboxes to Exchange 2010 SP2 and all of the mailboxes are running on ABPs with your ACLs decommissioned, you can start following the standard Exchange guidance for removing the Exchange 2007 organization. Removing and Modifying Exchange 2007 How to Remove an Exchange 2007 Organization If you get stuck, this Microsoft Knowledge Base article may help: How to Remove Exchange 2007 from a computer

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Calendar Repair

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-11-15 The Calendar Repair Assistant is a configurable mailbox assistant that runs within the Microsoft Exchange Mailbox Assistants service on Microsoft Exchange Server 2010 Mailbox servers. The Calendar Repair Assistant detects and corrects inconsistencies with single and recurring meeting items for mailboxes located on that Mailbox server. As a result, recipients won't miss meeting announcements or have unreliable meeting information. By default, the CRA is not set to run automatically. To configure the CRA to run and repair calendar inconsistencies, use the set-mailboxserver cmdlet in the Exchange Management Shell to set the work cycle and work cycle checkpoint. The Exchange Management Console cannot be used to configure calendar repair log settings. Contents Calendar Repair Assistant Tasks Conflict Detection and Resolution Calendar Repair Log Client Application Experience Looking for management tasks related to calendars? See Managing Calendars.

Calendar Repair Assistant Tasks

The Calendar Repair Assistant performs the following functions:

1. Detects inconsistencies The Calendar Repair Assistant uses the organizer's copy of the calendar item as a master copy for all meeting items. The assistant compares the attendee's calendar item with the organizer's calendar item for inconsistencies. The only exception to this rule is when the assistant compares the attendee's and organizer's response status. The assistant assumes that the attendee's response status is the correct one, and, if necessary, updates the organizer's tracking information. 2. Determines if inconsistencies were intentional If an inconsistency is detected, the Calendar Repair Assistant determines whether the attendee intentionally introduced the inconsistency. For example, an attendee can introduce an inconsistency by deleting the meeting request and not notifying the organizer. If the assistant determines that the attendee didn't introduce the inconsistency, it corrects the problem. If the assistant can't determine if the inconsistency was intentional, it performs no further action. 3. Corrects inconsistencies The Calendar Repair Assistant corrects inconsistencies on the Mailbox server on which it runs. However, if the organizer's mailbox is on a different server than the attendee's mailbox, the assistant reads from other Exchange 2010 Mailbox servers to compare the calendar items. The assistant doesn't overwrite the recipient's calendar information. Instead, it merges the information so data isn't lost. In addition, the repair update messages are moved to the recipient's Deleted Items folder. For more information about the inconsistencies detected and repaired, see Conflict Detection and Resolution later in this topic. 4. Sends a calendar repair update message if a correction was made Calendar repair update messages are sent to users whose calendar items were updated by the Calendar Repair Assistant. Instead of sending the message to the user's Inbox, the assistant sends the message to the user's Deleted Items folder. By doing so, a record of the repair is kept in the mailbox without causing user confusion. If the user is experiencing calendar inconsistencies, you can advise the user to look in the Deleted Items folder for troubleshooting purposes. The assistant only sends repair update messages if the issue is fixed. For more information about configuring the Calendar Repair Assistant, see Managing Calendars. Return to top

Conflict Detection and Resolution

The Calendar Repair Assistant detects and corrects the conflicts described in the following table.

Calendar Repair Assistant conflict resolution

Conflict An attendee accepted the organizer's meeting request or recurring meeting request, but the meeting isn't on the attendee's calendar. An attendee is missing an occurrence or exception within a recurring meeting series. Resolution The assistant checks the attendee's record in the mailbox database and finds that the attendee deleted the calendar item without sending a response. If the assistant can't determine that the meeting item was intentionally deleted by the attendee, the assistant creates the meeting request again. If the assistant determines that the attendee intentionally deleted the meeting request, no further action is taken. The assistant checks the organizer's copy for a deleted occurrence or exception and finds that the attendee deleted the meeting request without sending a response. If the assistant can't determine that the meeting item was intentionally deleted by the attendee, the assistant creates the meeting request again. If the assistant determines that the attendee intentionally deleted the occurrence or exception, no further action is taken. The assistant updates the organizer's tracking status with the status on the attendee's calendar item.

An attendee's response status for the meeting doesn't match the status on the organizer's calendar item. Attendees have the meeting on their calendars, but the organizer doesn't have those attendees listed in the attendee list.

The assistant adds the attendees to the organizer's list of attendees. Note:

If the meeting request was sent to a distribution group with more than 200 members, the Calendar Repair Assistant won't add the attendees to the organizer's attendee list.

An attendee is listed on some of the organizer's recurring meetings, but the attendee's recurrence pattern doesn't match the organizer's recurrence pattern. The location of an attendee's meeting doesn't match the location recorded in the organizer's calendar item. An attendee's start or end time is different from that of the organizer's start or end time. The organizer or attendee has multiple meetings that have the same MAPI property identifier: LIL_GLOBAL_OBJID.

The assistant replaces the attendee's recurrence pattern with the organizer's recurrence pattern.

If the attendee intentionally changed the meeting location, no action is taken. If the assistant can't determine that the location was intentionally changed by the attendee, the attendee's calendar item is appended with the meeting location on the organizer's calendar item. If the assistant determines that the attendee intentionally changed the time, no further action is taken. If the assistant determines that the conflict was unintentional, the start or end time is changed if either time differentiates more than two hours from the organizer's start or end time. The assistant compares all the duplicates and performs the following steps to correct the inconsistency: 1. Checks the sequence numbers of all the duplicates. The duplicate with the highest sequence number is kept. The other meeting items are deleted. 2. If the assistant can't determine which item to keep based on the sequence number, it checks the OwnerCriticalChangeTime property. If one of the duplicates is the most recent copy, it keeps that duplicate item. The other meeting items are deleted. 3. If the assistant can't determine which item to keep based on the most recent copy, it checks the LastModifiedTime property. If one of the duplicates has the last modified time, the assistant keeps that duplicate item. The other meeting items are deleted. 4. If the assistant can't determine which item to keep based on the last modified time, it keeps the first calendar item returned by the database when querying for duplicate meetings. The other meeting items are deleted.

An attendee has a single or recurring meeting on his or her calendar, but the organizer doesn't have this item on his or her calendar. Return to top

The assistant checks whether the organizer intentionally deleted the meeting. If the organizer intentionally deleted the meeting, the assistant sends a cancellation to the attendees. If the assistant determines that the organizer didn't intentionally delete the meeting, the meeting is added back to the organizer's calendar. If the assistant can't determine the organizer's intent, no action is performed.

Calendar Repair Log

Every time the Calendar Repair Assistant changes a calendar item on a user's mailbox, it writes the change to a calendar repair log (.log) file. The output of this .log file doesn't reveal personal data, such as the body of the message or attachments. The file only contains the minimum information to identify the meeting that was repaired and what repair actions were taken. Each time the assistant runs, one calendar repair log file is created for every mailbox. By default, calendar repair logging is enabled. The calendar repair log is configurable and can be turned on or off for a server or user. For more information, see Managing Calendars. The default calendar repair log path is <Exchange Installation Path>\v14\Logging\Calendar Repair Assistant. The log files are created with the following naming convention: CRAYYYYMMDDHH-X.Alias.log

CRA = Calendar Repair Assistant prefix YYYY = year MM = month DD = day HH = hour X = instance Alias = mailbox alias For example, the following repair log file indicates that a repair was made on Tony's mailbox on April 18, 2010, at 15:00 (3:00 P.M.), and that the repair was the third one made within that hour: CRA2010041815-3.tony.log Return to top

Client Application Experience

The Calendar Repair Assistant can't access the same data for all client applications. As a result, users may get a different experience depending on which client application they use to review mail. Therefore, the assistant may not be able to determine if the action made by the user was intentional. As previously stated, the assistant corrects conflicts only if it can successfully determine that the attendee didn't intentionally introduce the conflict. If the assistant can't make this determination, no further action is taken. The following table lists the different end-user calendaring tasks that could result in a calendar conflict. Based on which client application was used, the Calendar Repair Assistant can determine the user's intent.

Calendaring tasks
Scenario Client application Property recorded

Organizer opens the calendar item and modifies its properties.

Microsoft Office Outlook Web App Client applications that use Exchange Web Services Mobile client applications that use Microsoft Exchange ActiveSync

ModifiedStartTime ModifiedEndTime ModifiedLocation

Organizer drags the meeting in his or her calendar view to a different time.

Outlook Web App Client applications that use Exchange Web Services Note: This scenario isn't supported for client applications that use Exchange ActiveSync.

ModifiedStartTime ModifiedEndTime

Attendee responds as either accepted or tentatively accepted with or without sending a response message to the organizer.

Outlook Web App Client applications that use Exchange Web Services Mobile client applications that use Exchange ActiveSync

RespondedAccepted RespondedTentative

Attendee declines a meeting request with or without sending a response message to the organizer.

Outlook Web App Client applications that use Exchange Web Services Mobile client applications that use Exchange ActiveSync

DeletedWithNoResponse RespondedDeclined

Attendee declines an instance of a recurring meeting request with or without sending a response message to the organizer.

Outlook Web App Client applications that use Exchange Web Services Mobile client applications that use Exchange ActiveSync

DeletedExceptionWithNoResponse RespondedExceptionDecline

Organizer cancels a meeting.

Outlook Web App Client applications that use Exchange Web Services Mobile client applications that use Exchange ActiveSync

MeetingExceptionCanceled

Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding E-Mail Address Policies

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-04-28 Recipients (which include users, resources, contacts, and groups) are any mail-enabled object in Active Directory to which Microsoft Exchange can deliver or route messages. For a recipient to send or receive e-mail messages, the recipient must have an e-mail address. E-mail address policies generate the primary and secondary email addresses for your recipients so they can receive and send e-mail. By default, Exchange contains an e-mail address policy for every mail-enabled user. This default policy specifies the recipient's alias as the local part of the e-mail address and uses the default accepted domain. The local part of an e-mail address is the name that appears before the at sign (@). However, you can change how your recipients' e-mail addresses will display. For example, you can specify that your recipients' e-mail addresses display as firstname.lastname@contoso.com. Furthermore, if you want to specify additional e-mail addresses for all recipients or just a subset, you can modify the default policy or create additional policies. For example, the following figure illustrates a configuration in which the recipient David Hamilton can receive e-mail messages addressed to hdavid@mail.contoso.com and hamilton.david@mail.contoso.com.

Looking for management tasks related to e-mail address policies? See Managing E-Mail Address Policies.

Behaviors of Recipient Policies

Exchange applies a policy to all recipients that match the recipient filtering criteria:

The recipient policy functionality is divided into two features: e-mail address policies and accepted domains. Note: A detailed discussion about accepted domains is outside the scope of this topic. For information about accepted domains, see Understanding Accepted Domains. When you run the Update-EmailAddressPolicy cmdlet in the Exchange Management Shell, the recipient object is updated with the e-mail address policy. For detailed syntax and parameter information, see Update-EmailAddressPolicy. Each time a recipient object is modified and saved, Exchange enforces the correct application of the e-mail address criteria and settings. When an e-mail address policy is modified and saved, all associated recipients are updated with the change. In addition, if a recipient object is modified, that recipient's e-mail address policy membership is reevaluated and enforced.

Creating E-Mail Address Policies

When creating an e-mail address policy, you can use the following e-mail address types:

Precanned SMTP e-mail address. Precanned SMTP e-mail addresses are commonly used e-mail address types provided for you. Custom SMTP e-mail address. If you don't want to use one of the precanned SMTP e-mail addresses, you can specify a custom SMTP e-mail address. When creating a custom SMTP e-mail address, you can use the variables in the following table to specify alternate values for the local part of the e-mail address.

Custom SMTP e-mail address

Variable Value

%g %i %s %d %m % xs % xg

Given name (first name) Middle initial Surname (last name) Display name Exchange alias Uses the first x letters of the surname. For example, if x = 2, the first two letters of the surname are used. Uses the first x letters of the given name. For example, if x = 2, the first two letters of the given name are used.

Non-SMTP e-mail address. The following types of non-SMTP e-mail addresses are supported: EX (Legacy DN Proxy Address Prefix DisplayName) X.500 X.400 MSMail CcMail Lotus Notes Novell GroupWise Exchange Unified Messaging proxy address (EUM proxy address) Important: In Exchange, all non-SMTP e-mail addresses are considered custom addresses. Exchange doesn't provide unique dialog boxes or property pages for X.400, GroupWise, or Lotus Notes e-mail address types. If you add a non-SMTP custom e-mail address, you must have the appropriate dynamic-link library (DLL) files. If you don't provide the appropriate DLL files, you won't be able to create a customized e-mail address policy. The following error will be logged in Event Viewer: "The e-mail address description object in the Microsoft Exchange directory for the 'SADF' address type on 'i386' machines are missing." For detailed instructions about how to create an e-mail address policy, see the following topics:

Create an E-Mail Address Policy Create an E-Mail Address Policy By Using Recipient Filters

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding the Exchange 2010 Store

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2013-03-13 The Exchange store is a storage platform that provides a single repository for managing multiple types of information in one infrastructure. The Exchange store (store.exe) is the core data storage repository for Microsoft Exchange Server 2010. Contents Databases in Editions of Exchange 2010 Logical Components of the Exchange Store File Structure of the Exchange Store Understanding Transaction Logging Extensible Storage Engine Store Health Low Disk Space on Database Logs or Database Drives Exchange Store Limits

Databases in Editions of Exchange 2010

Exchange 2010 is available in two server editions: Standard Edition and Enterprise Edition. Exchange 2010 Standard Edition is designed to meet the messaging and collaboration needs of small and medium corporations, and it may also be appropriate for specific server roles or branch offices. Exchange 2010 Enterprise Edition is designed for large enterprises. Exchange 2010 Standard Edition supports up to five databases. Exchange 2010 Enterprise Edition supports up to 100 databases.

Logical Components of the Exchange Store

The primary components of the Exchange store are mailbox databases and public folder databases. These components can reside on a single server, or they can be distributed across multiple servers. Mailbox databases contain the data, data definitions, indexes, checksums, flags, and other information that comprise mailboxes in Exchange 2010. Mailbox databases hold data that's private to an individual user and contain mailbox folders generated when a mailbox is created for that user. A mailbox database is stored as an Exchange database (.edb) file. Public folder databases contain the data, data definitions, indexes, checksums, flags, and other information that comprise any public folders in your Exchange organization. In Exchange 2010, you manage public folders by using the Exchange Management Shell. (You can also perform a limited number of public folder database management tasks in the Exchange Management Console.) For more information about managing public folders, see Managing Public Folders and Understanding Public Folders. Return to top

File Structure of the Exchange Store

You manage the Exchange store by working with its logical components, such as databases. However, Exchange 2010 stores data in a specialized set of data files, such as Exchange database (.edb) files, transaction log (.log) files, and checkpoint (.chk) files. Unless you're backing up or restoring data, you rarely interact with these files directly. The following table describes each of these files in more detail.

File structure of Exchange store

Data file Exchange database (.edb) Description These files are the repository for mailbox data. They're accessed by the Extensible Storage Engine (ESE) directly and have a B-tree structure designed for quick access. This enables users to access any page of data within one input/output (I/O) cycle, which is a four-fold increase compared to Microsoft Exchange Server 2007. Exchange databases are composed of multiple B-trees, with ancillary trees that work with the main tree by holding indexing and views. These files are the repository for database operations such as creating or modifying a message. Committed operations are later written to the database itself (in an .edb file). This approach guarantees that all complete and incomplete transactions are logged to maintain data integrity in case of a service interruption. Each database has its own set of transaction logs. These files are the repository for data that indicates when an operation is successfully saved to the database on the hard disk. Exchange 2010 uses .chk files so an instance of the ESE can automatically replay log files into an inconsistent database when recovering from a service interruption, starting with the next unwritten operation. The .chk files are placed in the same log location as the .log files.

Transaction log (.log)

Checkpoint (.chk)

Return to top

Understanding Transaction Logging

Exchange transaction logging is a robust recovery mechanism of the ESE designed to reliably restore an Exchange database to a consistent state after any sudden stop of the database. The logging mechanism is also used when restoring online backups. This section describes the details of Exchange 2010 transaction logging and includes a brief description of circular logging.

Exchange Transaction Logging

Before changes are made to an Exchange database file, Exchange writes the changes to a transaction log file. After a change is safely logged, it can then be written to the database file. It's common for these changes to become available to end users just after the changes are secured to the transaction log, but before the changes are written to the database file. Exchange employs a sophisticated internal memory management system tuned for high performance, which efficiently manages the caching of dozens of gigabytes (GB) of database pages. Physically writing changes to the database file is a low-priority task during normal operation. If a database suddenly stops, cached changes aren't lost just because the memory cache was destroyed. When the database restarts, Exchange scans the log files, and reconstructs and applies any changes not yet written to the database file. This process is called replaying log files. The database is structured so that Exchange can determine whether any operation in any log file has already been applied to the database, needs to be applied to the database, or doesn't belong to the database. Rather than write all log information to a single large file, Exchange uses a series of log files, each exactly one megabyte (MB), or 1,024 kilobytes (KB), in size. When a log file is full, Exchange closes it and renames it with a sequential number. The first log filled ends with the name Enn00000001.log. The nn refers to a two-digit number known as the base name or log prefix. Log files for each database are distinguished by file names with numbered prefixes (for example, E00, E01, E02, or E03). The log file currently open for a database is named Enn.log. It doesn't have a sequence number until it has been filled and closed. The checkpoint file (Enn.chk) tracks how far Exchange has progressed in writing logged information to the database files. There's a checkpoint file for each log stream, and a separate log stream for each database. Log files are numbered in a hexadecimal manner, so the log file after E0000000009.log is E000000000A.log, and not E0000000010.log. You can convert log file sequence numbers to their decimal values by using the Windows Calculator (Calc.exe) application in Scientific mode. To do this, run Calc.exe, and then from the View menu, click Scientific. To view the decimal sequence number for a specific log file, you can examine its header by using the Exchange Server Database Utilities (Eseutil.exe) tool. The first 4KB page of each log file contains header information that describes and identifies the log file and the databases it belongs to. The command Eseutil /ml [log file name] displays the header information. If you use the wrong switch for displaying a header (for example, by using /ml with a database header instead of /mh), an error is displayed or the header information displayed may be garbled or incorrect. You can't view the header of a database while it's mounted. You also can't view the header of the current log file (Enn.log) while any database is mounted. Exchange holds the current log file open as long as one database is using it. However, you can view the checkpoint file header while databases are mounted. Exchange updates the checkpoint file every thirty seconds, and its header is viewable except during the moment when an update is occurring. As an Exchange administrator, it's valuable to understand Exchange file headers. If you understand file headers, you can determine which database and log files belong together and which files are needed for successful recovery. In the following log file header example, note the first four lines.

Base name: e00 Log file: e00.log lGeneration: 11 (0xB) Checkpoint: (0xB,7DC,6F)

These log file header lines show that this log file is the current log file because the log file name doesn't have a sequence number. The lGeneration line shows that when the log is filled and closed, its sequence number is B, corresponding to the decimal value 11. The base name is e00, and therefore the final log file name will be E000000000B.log. The Checkpoint value in the previous header example isn't actually read from the log file header, but it's displayed as if it were. Eseutil.exe reads the Checkpoint value directly from Enn.chk, so you don't have to enter a separate command to learn where the checkpoint file is. If the checkpoint file has been destroyed, the Checkpoint value reads NOT AVAILABLE. In this case, the checkpoint is in the current log file (0xB), and the numbers 7DC and 6F indicate how far into the log file the checkpoint is. Note that you seldom have a practical need for this information. If the checkpoint file is destroyed, Exchange can still recover and replay log files appropriately. But to do so, Exchange begins scanning log files, beginning with the oldest file available, instead of starting at the checkpoint log. Exchange skips data that has already been applied to the database and works sequentially through the logs until data that must be applied is encountered. Typically, it takes only one or two seconds for Exchange to scan a log file that has already been applied to the database. If there are operations in a log file that must be written to the database, it can take anywhere from 10 seconds to several minutes to apply them. On average, a log file's contents can be written to the database in 30 seconds or less. When an Exchange database shuts down normally, all outstanding data is written to the database files. After normal shutdown, the database file set is considered consistent, and Exchange detaches it from its log stream. This means that the database files are now self-contained (up to date). The transaction logs aren't required to start the database files. You can tell whether a database has been shut down cleanly by running the command Eseutil /mh and examining the file headers.

With all databases disconnected and in a Clean Shutdown state, all log files can be safely deleted without affecting the databases. If you were then to delete all log files, Exchange would generate a new sequence of logs starting with Enn00000001.log. You could move the database files to a different server that has existing log files, and the databases would attach themselves to a different log stream. Note: Although you can delete the log files after all databases have been shut down, doing so affects your ability to restore older backups and roll forward. The current database no longer needs the existing log files, but they may be necessary if you must restore an older database. If a database is in a Dirty Shutdown state, all existing transaction logs from the checkpoint forward must be present before you can mount the database again. If these logs are unavailable, you must repair the database by running the command Eseutil /p to make the database consistent and ready to start.

Caution: If you have to repair a database, some data will be lost. Data loss is frequently minimal; however, it may be catastrophic. After running Eseutil /p on a database, you should run Eseutil/ d to defragment the database. This operation discards and rebuilds all database indexes and space trees. In addition to allowing Exchange to recover reliably from an unexpected database stop, transaction logging is also essential to making and restoring online backups. For more information about making and restoring online backups, see Understanding Backup, Restore and Disaster Recovery. Return to top

Circular Logging
You can configure Exchange to save disk space by enabling circular logging. Circular logging allows Exchange to overwrite transaction log files after the data that the log files contain is committed to the database. However, if circular logging is enabled, you can recover data only up until the last full backup. For example, you can enable circular logging when using Exchange native data protection, in which you don't make backups. To prevent log buildup, you need to enable circular logging. In the standard transaction logging used by Exchange 2010, each database transaction is written to a log file and then to the database. When a log file reaches one MB in size, it's renamed, and a new log file is created. Over time, this results in a set of log files. If Exchange stops unexpectedly, you can recover the transactions by replaying the data from these log files into the database. Circular logging overwrites and reuses the first log file after the data it contains has been written to the database. In Exchange 2010, circular logging is disabled by default. By enabling it, you reduce drive storage space requirements. However, without a complete set of transaction log files, you can't recover any data more recent than the last full backup. In a normal production environment, circular logging isn't recommended. For information about how to enable and disable circular logging, see Configure Mailbox Database Properties. Return to top

Extensible Storage Engine

Exchange mailbox databases and the queue on Hub Transport servers and Edge Transport servers utilize the ESE database. ESE is a multiuser, indexed sequential access method (ISAM) table manager with full data manipulation language (DML) and data definition language (DDL) capability. ESE allows applications to store records and create indexes to access those records in different ways. For more information about ESE, see Extensible Storage Engine Architecture. For improvements in Exchange 2010 ESE, see New Exchange Core Store Functionality. Return to top

Store Health
The Exchange store can detect and correct several scenarios that can cause the store to become unhealthy. The Exchange store can handle poison mailboxes and thread time-outs, use report and alert features to signal an unhealthy Exchange store state, and detect and repair mailbox database and public folder database issues.

Poison Mailbox Detection and Correction

A single mailbox with corrupted data (logical or physical) may in some cases cause the Exchange store to fail, and deny service to all mailboxes hosted by the server. Similarly, a poison mailbox could also cause the Exchange store to repeatedly fail. This section describes the actions the Exchange store takes to detect and cut off poison mailboxes.

Isolating the Poison Mailbox

There are several types of events for which the Exchange store tags a mailbox as a potential threat:

If a thread doing work for that mailbox fails If there are more than five threads in that mailbox that haven't made progress for a long time A mailbox that's a potential threat is tagged, along with a count of how many times it has been tagged. This information is stored in the registry. The Exchange store also keeps timestamp information about when the mailbox was identified as a potential threat. During a database mount, the Exchange store reads the time that the mailboxes were identified as potential threats. If more than two hours has elapsed, the registry key for the mailbox is deleted. The advantage of keeping this information in the registry is that in a high availability environment, it's replicated by the cluster database. Even during an Exchange store failover, the other computers have this information. The registry subkey thats used to isolate the poison mailbox is HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\Private-{db guid}\QuarantinedMailboxes\{mailbox guid}. The keys for this path are CrashCount and LastCrashTime.

The settings for the amount of failures that lead to quarantining a mailbox and also for the amount of time that a mailbox should stay quarantined are stored in the MailboxQuarantineCrashThreshold and MailboxQuarantineDurationInSeconds keys in the HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\Private-{db guid} subkey. The default values for these keys are three failures for MailboxQuarantineCrashThreshold and 21,600 seconds (six hours) for MailboxQuarantineDurationInSeconds.

Acting on the Poison Mailbox

By default, if a mailbox is identified as causing a failure or deadlock three times within two hours, the Exchange store tags it as quarantined in the registry. No access is allowed to the mailbox unless the OPEN_AS_ADMIN flag is passed. None of the Exchange processes (for example, content indexing or the Mailbox assistants) are allowed to log on. The QuarantineState and QuarantineTime registry keys keep track of whether the mailbox is quarantined. If the mailbox hasn't caused any failures in the last two hours and isn't quarantined, the registry path for the mailbox is cleaned up by the Exchange store. If a mailbox has been quarantined for longer than the MailboxQuarantineDurationInSeconds value since its LastCrashTime value, it's released from quarantine automatically.

Resetting the Quarantined Mailbox

When the cause of the poison mailbox has been identified and corrected, the registry key for the quarantined mailbox should be reset manually by deleting it. However, if this manual step is forgotten, the Exchange store automatically resets quarantined mailboxes six hours after the quarantined flag was set. If the issue isn't debugged and fixed within that time period, this may lead to another set of failures before the mailbox or message is quarantined again. Note: The database hosting the mailbox needs to be remounted, or the Exchange store restarted, for the reset of the quarantined mailbox to take effect. The time period for resetting quarantined mailboxes can be controlled by the registry key HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\Private-{db guid}\QuarantinedMailboxes\MailboxQuarantineDurationInSeconds.

Reporting and Alerts

You can use the Get-MailboxStatistics cmdlet to report the quarantined state of a mailbox. The Exchange store has a Performance Monitor counter for the number of quarantined mailboxes. The counter name is MSExchangeIS Mailbox\Quarantined Mailbox Count. The Exchange store also writes an event whenever it quarantines a mailbox, with details about which mailbox and what time. The event 10018 identifies a quarantined mailbox. Return to top

Database Repair
In Exchange 2010 Service Pack 1 (SP1), you can use the New-MailboxRepairRequest cmdlet to detect and repair mailbox corruptions. You can run this cmdlet against a specific mailbox or against a mailbox database. While this task is running, mailbox access is disrupted for the mailbox being repaired. If you run this cmdlet against a mailbox database, only access to the mailbox being repaired is disrupted. All other mailboxes in the database remain operational. For more information, see Create a Mailbox Repair Request. The New-MailboxRepairRequest cmdlet detects and repairs the following types of mailbox corruptions:

Search folder corruptions (using the SearchFolder value of the CorruptionType parameter) Aggregate counts on folders that aren't reflecting correct values (using the AggregateCounts value of the CorruptionType parameter) Views on folders that aren't returning the correct content (using the FolderView value of the CorruptionType parameter) Provisioned folders incorrectly pointing to parent folders that aren't provisioned (using the ProvisionedFolder value of the CorruptionType parameter) After you run the New-MailboxRepairRequest cmdlet, you can use Event Viewer to view the details of the request. For more information, see View Mailbox Repair Request Entries in Event Viewer. You can also use the New-PublicFolderDatabaseRepairRequest cmdlet to detect and fix replication issues in the public folder database. Public folders in the public folder database can still be accessed while the request is running. However, access isn't available to the public folder currently being repaired. For more information, see Create a Public Folder Database Repair Request. Return to top

Time-Out Detection and Reporting

Another indication of an unhealthy Exchange store is that threads are either deadlocked or otherwise not making any progress. If there are more than five threads on a single mailbox, ten threads on a single database, or twenty threads on a single server that hasn't made progress in one minute, a time-out is reported on the server. The performance counter that indicates detected time-outs is MSExchangeIS\ RPC Request Timeout Detected. The Exchange store also writes the following events to the server:

10025, which reports a time-out on the Exchange server 10026, which reports a time-out on the database 10027, which reports a time-out on an individual mailbox

If the time-out is detected on a single mailbox, the mailbox is considered potentially poison, and is handled similar to a failure by increasing the CrashCount key. This makes it susceptible to being quarantined. Return to top

Low Disk Space on Database Logs or Database Drives

When the Exchange store detects that the space available on a log or database drive is below 1 GB, it cuts off all transport delivery to that database. This is to prevent a disk running out of space. When a disk runs out of space, the database can't be mounted or debugged. The database space also can't be reclaimed. This is a selfprotecting mechanism that only occurs if you don't react to the space issue warnings from your monitoring infrastructure. When the disk space goes above 1.5 GB, the Exchange store allows deliveries to continue. The following performance counters indicate this behavior:

MSExchangeIS Mailbox\ Delivery Blocked: Low Database Space MSExchangeIS Mailbox\ Delivery Blocked: Low Log Space The Exchange store also writes the following events to the server:

10014, which indicates low disk space on the log 10015, which indicates low disk space on the database If you encounter low disk space issues, you can perform the following actions to correct the issue:

Delete content from mailboxes. Specifically, you can delete messages from the Deleted Items and Sent Items folders. Purge items from the Recoverable Items folder. For details, see Clean Up the Recoverable Items Folder. Run database maintenance. For details, see Maintain Mailbox Databases. Purge transaction logs. For details, see Understanding High Availability Factors. Enable circular logging. For details, see Configure Mailbox Database Properties. Change the database path to a hard disk drive that has more space. For details, see Move the Mailbox Database Path for a Mailbox Database Copy. Return to top

Exchange Store Limits

In Exchange 2010, connection and usage limits are placed on the Exchange store to prevent a single application or a single user from using all the available connections to the Exchange store. If a single user or application uses all the connections, other users or applications won't be able to access the Exchange store, which can result in downtime. For more information, see Exchange Store Limits. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Exchange Store Limits

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-03-08 In Microsoft Exchange Server 2010, connection and usage limits have been placed on the Exchange store to prevent a single application or a single user from using all the available connections to the Exchange store. If a single user or application is allowed to use all of the connections, other users or applications cannot be able to access the Exchange store, which could result in downtime. Note: For any connections made by accounts that have administrative privileges, the session limits have been increased to 64,000 maximum sessions per server. Contents Terminology Session Limits Open Item Limits Item Size Limits

Terminology
Knowledge of the following terms will help you understand the types of connections referenced in this topic.

Sessions Sessions represent the connections used by services and client applications, such as Microsoft Outlook, to connect to the Exchange store. Services and clients can have multiple sessions at a particular time. The terms connections and sessions can be used interchangeably.

Threads Threads represent concurrently executing requests to the Exchange store. For example, if a user opens a folder in Outlook, Outlook executes a request to the Exchange store on behalf of the user. That executing request is a single thread. For example, 75 users being logged on to a server at the same time is equal to 75 sessions. However, out of those 75 sessions, only 5 of those sessions could be making requests through threads.

Return to top

Session Limits
The following table lists the types of client connections to the Exchange store and the limits based on those connections. If you want to modify the session limits, see "Configure Session Limits" immediately following the table. The types of connections are as follows:

Max concurrent threads per server Specifies the maximum number of concurrent threads that an Exchange service can execute on a Mailbox server. Max sessions per server Specifies the maximum number of sessions that an Exchange service can have open at one time on a Mailbox server. Max user sessions per server Specifies the maximum number of sessions for a particular protocol for a single user.

Client type Admin Availability service Content indexing Exchange ActiveSync Exchange Web Services Management MAPI on the Middle Tier (MoMT) MSExchangeMailboxAssistants: Events MSExchangeMailboxAssistants: Timed

Max concurrent threads per server 50 50 50 Not applicable Not applicable Not applicable Not applicable 50 50

Max sessions per server 10,000 10,000 10,000 Not applicable Not applicable Not applicable Not applicable 10,000 10,000

Default number of user sessions per server Not applicable 16 Not applicable 16 16 16 32 Not applicable Not applicable

MSExchange Remote Procedure Call Microsoft Office Outlook Web App POP3 and IMAP4 Transport Unified Messaging Others

Not applicable Not applicable Not applicable 50 Not applicable Not applicable

Not applicable Not applicable Not applicable 10,000 Not applicable Not applicable

16 16 16 Not applicable 16 16

Configure Session Limits

You can modify the default session limits. Note: If you want to modify the session limits, you need to modify them on all Mailbox servers within any database availability groups (DAGs). If you don't make the same changes on all servers, the results will be inconsistent. To increase the session limit on the Client Access server, the RCAMaxConcurrency value must be increased on the throttling policy. For more information, see Set-ThrottlingPolicy. Caution: Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data. 1. Start Registry Editor (regedit). 2. Navigate to the following registry subkey: \\HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem. 3. Right-click ParametersSystem, point to New, and then click DWORD (32-bit) Value. The new value is created in the result pane. 4. Rename the key to one of the following values, and then press Enter: Maximum Allowed Sessions Per User This limit specifies the maximum allowable sessions per user. Maximum Allowed Service Sessions Per User This limit specifies the maximum allowed service sessions per user. Maximum Allowed Exchange Sessions Per Service This limit specifies the maximum allowed Exchange sessions per service. The default value is 10,000, and the Maximum value is 65536. Maximum Allowed Concurrent Exchange Sessions Per Service This limit specifies the maximum allowed concurrent Exchange sessions per service. Disable Session Limit This limit disables session limits. Set the value to 0 to turn off session limits. Set the value to 1 to turn on session limits. 5. Right-click the newly created key, and then click Modify. 6. In the Value data box, type the number of objects to which you want to limit this entry, and then click OK. Use the preceding table to view the default settings. Return to top

Open Item Limits

Open item limits are limits placed on the number of items that can be opened by a single mailbox in a single session. However, a user can have multiple sessions opened simultaneously. For example, if a user has two sessions opened, the user could open 1,000 folders. If you want to modify these limits, see "Configure Open Item Limits" immediately following the table.

Item type ACL View Attachment Attachment View Cstream Folder Folder View FX Destination Stream FX Source Stream Message Message View Notification

Registry object type objtACLView objtAttachment objtAttachmentView objtCStream objtFolder objtFolderView objtFXDstStrm objtFXSrcStrm objtMessage objtMessageView objtNotify

Max opened per session 50 500 500 50 500 500 50 50 250 500 500,000

Rule View Stream

objtRulesView objtStream

50 250

Configure Open Item Limits

You can limit the maximum number of resources that a MAPI client can use simultaneously. Note: If you want to modify the open item limits, you need to modify them on all Mailbox servers within any DAGs and client access arrays. If you don't make the same changes on all servers, the results will be inconsistent. Caution: Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data. 1. Start Registry Editor (regedit). 2. Navigate to the following registry subkey: \\HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem 3. Right-click ParametersSystem, point to New, and then click Key. A new key is created in the console tree. 4. Rename the key MaxObjsPerMapiSession, and then press Enter. 5. Right-click MaxObjsPerMapiSession, point to New, and then click DWORD (32-bit) Value. The new value is created in the result pane. 6. Rename the key to <Object_type>, where <Object_type> is the name of the registry object type that you're modifying. For example, to modify the number of messages that can be opened, use objtMessage. Press Enter. 7. Right-click the newly created key, and then click Modify. 8. In the Value data box, type the number of objects that you want to limit this entry to, and then click OK. For example, type 350 to increase the value for the object. 9. Restart the Microsoft Exchange Information Store service. Return to top

Item Size Limits

Item size limits are the limits placed on items within a user's mailbox. Item size limits are configurable by using the MaxSendSize and MaxReceiveSize parameters on the following cmdlets:

Set-Mailbox Set-RemoteMailbox Set-MailUser Set-MailContact

Item type Message (saved) Message (sent) Attachments Return to top

Limit Maximum size of the SendLimit, ReceiveLimit Maximum size of the SendLimit Maximum number of attachments per message = 1,024

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Database Maintenance

Applies to: Exchange Server 2010 SP3 Topic Last Modified: 2012-08-24 Architectural changes that were made to the database engine in Microsoft Exchange Server 2010 significantly improve its performance and robustness. However, these architectural changes also change the behavior of database maintenance tasks from earlier versions of Exchange Server. This topic describes the database maintenance tasks that must be routinely performed against Exchange Server 2010 databases. All the tasks that are described in this topic are collectively known as background database maintenance.

Database Compaction
Database compaction must be completed to free up unused space in the database file. Database compaction does not return that unused space to the file system. Instead, it frees pages in the database by compacting records into the fewest possible number of pages, and reduces the I/O that is required to access the pages. To do this, the ESE database engine uses the database metadata, which is the information that describes tables in the database. For each table, the ESE database engine examines every page in the table, and tries to move the records to logically ordered pages. Database compaction is important because it reduces the time associated with backing up the database file, and it helps maintain a predictable database file size. This is important to accurately determine server/storage size. Database compaction was redesigned for Exchange Server 2010. Most significantly, the operation now gives preference to data contiguity over the amount of compaction. In earlier versions of Exchange Server, the focus was greater on space compaction. This resulted in pages that were always in random order after the process reordered records into free space across pages. In combination with the store schema architecture, this random reordering meant that any request to pull a set of data (such as downloading items inside a folder) always resulted in random I/O. In Exchange Server 2010, random I/O is reduced by keeping records in order on the pages. Also in earlier versions of Exchange Server, database compaction operations were performed during the online maintenance window. In Exchange 2010, database compaction is now a background process that runs continuously.

Database Defragmentation
Database defragmentation (also known as OLD v2 and B+ tree defragmentation) is a new maintenance task in Exchange Server 2010. Database defragmentation is important to maintain efficient utilization of disk resources over time (i.e., make the I/O more sequential instead of random) and to maintain the compactness of tables that are marked as sequential. Database defragmentation is a background process that analyzes the database continuously as operations are performed, and then triggers asynchronous work when it is necessary. The process monitors all tables for free pages. If a table reaches a threshold at which a significantly high percentage of the total B+ Tree page count is free, the free pages are returned to the root. The process also works to maintain contiguity throughout a table set with sequential space hints (a table that was created with a known sequential usage pattern). If database defragmentation sees a scan/pre-read on a sequential table, and if the records are not stored on sequential pages within the table, the process defragments that section of the table by moving all the affected pages to a new extent in the B+ tree. You can use performance counters to see the low level of active work performed by database defragmentation when a steady state is reached. Database defragmentation has the following controls to regulate how it completes tasks:

The max number of outstanding tasks This keeps database defragmentation from doing too much work during the first pass if a very large change has occurred in the database. A latency throttle of 100ms When the system is overloaded, database defragmentation will delay defragmentation work. Delayed work is completed the next time that the database follows that same operational pattern and the system has more resources.

Online database scanning (Database Checksumming)

Online database scanning (also known as database checksumming) is the process by which the database is read in large chunks, and every page is examined for physical page corruption. The main purpose of checksumming is to detect physical corruption and lost flushes that may not be detected by transactional operations (stale pages). Note: In Exchange Server 2007 and earlier versions, the checksumming operations occurred during the backup process. However, this caused a problem for replicated databases because only the copy that was being backed up was checksummed. If the passive copy was backed up, the active copy was not being checksummed. To resolve this issue, a new optional online maintenance task named Online Maintenance Checksum was added to Exchange Server 2007 Service Pack 1 (SP1). For more information, see How to Configure Online Maintenance Database Scanning in Exchange 2007 SP1 and SP2. In Exchange 2010, online database scanning checksums the database and performs post Exchange 2010 Store crash operations. Space can leak because of crashes. Online database scanning finds and recovers lost space. The system in Exchange 2010 is designed with the expectation that every database is fully scanned one time every seven days. A warning event is fired if a database is not completely scanned in this timeframe. In Exchange 2010, there are now two modes to run online database scanning on active database copies:

Run as the last task in the scheduled Mailbox Database Maintenance process: You can configure how long it runs by changing the Mailbox Database Maintenance schedule. You can use this option for smaller databases that are less than 1 terabyte and that require less time to be completely scanned. Run the default behavior in the background 24 hours a day, seven days a week: This option works well for all database sizes, but we recommend this for large database sizes (1-2 TB). Exchange scans the database no more than one time per day. This read I/O is 100 percent sequential (which makes it easy on the disk), and equates to a scanning rate of about 5 megabytes (MB)/sec on most systems.

Note:

The Shell, EMC, and JetStress refer to database checksumming as background database maintenance. To enable database checksumming in the EMC, select the Enable background database maintenance (24 X 7 ESE scanning) check box in Properties. To enable database checksumming in the shell, enter the following cmdlet: Set-MailboxDatabase -Identity MDB1 -BackgroundDatabaseMaintenance $true To enable database checksumming in Jetstress 2010, select the Run background database maintenance check box on the Select Test Type page.

Page Patching
Page patching replaces corrupted pages with healthy copies. Corrupted page detection is a function of database checksumming. In addition, corrupted pages are detected at run time when the page is stored in the database cache. Page patching works against highly available (HA) database copies. How a corrupted page is repaired depends on whether the HA database copy is active or passive. Page patching process on active database copies

A corrupted page(s) is detected. A marker is written into the active log file. This marker indicates the corrupted page number. It also indicates that the page requires replacement. An entry is added to the page patch request list. The active log file is closed. The Replication service sends the log file to passive database copies. The Replication service on a target Mailbox server receives the sent log file and inspects it. The Information Store on the target server replays the log file, and replays up to marker, retrieves its healthy version of the page, invokes Replay Service callback, and then ships the page to the source Mailbox server. The source Mailbox server receives the healthy version of the page, confirms that an entry exists in the page patch request list, and then writes the page to the log buffer. Correspondingly, the page is inserted into the database cache. The corresponding entry in the page patch request list is removed. At this point, the database is considered patched. (At some later point, the checkpoint will advance, the database cache will be flushed, and the corrupted page on disk will be overwritten.) Any other copy of this page (received from another passive copy) will be silently dropped. This is because no corresponding entry exists in the page patch request list. Page patching process on passive database copies

On the Mailbox server on which the corrupted pages are detected, log replay is paused for the affected database copy. The replication service coordinates with the Mailbox server that is hosting the active database copy, and it retrieves the corrupted pages and the required log range from the active copys database header. The Mailbox server updates the database header for the affected database copy, and it inserts the new required log range. The Mailbox server notifies the Mailbox server that is hosting the active database copy about which log files it requires. The Mailbox server receives the required log files, and it inspects them. The Mailbox server injects the healthy versions of the database pages it retrieved from the active database copy. The pages are written to the log buffer. Correspondingly, the page is inserted into the database cache. The Mailbox server resumes log replay.

Page Zeroing
Database Page Zeroing is a security measure by which deleted pages in the database are overwritten with a pattern (zeroed). This makes discovering the data much more difficult. In Exchange Server 2007 and earlier versions, page zeroing operations occur during the streaming backup process. Because they occur during the streaming backup process, page zeroing does not cause the generation of log files. This raises an issue for replicated databases because the passive copies never have their pages zeroed. Also, the active copies have their pages zeroed if a streaming backup is finished. In Exchange Server 2007 SP1, we introduced a new optional online maintenance task to address this issue: Zero Database Pages during Checksum. When Zero Database Pages during Checksum is enabled, this task zeroes out pages during the online maintenance window, and then logs the changes. The changes are then replicated to the passive copies. However, in the Exchange Server 2007 SP1 implementation, the zeroing process occurs during a scheduled maintenance window. This creates a delay between the time that a page is deleted and the time that it is zeroed. Therefore, the page zeroing task becomes a runtime event that operates continuously in Exchange Server 2010 SP1. Typically, the task now zeroes out pages at transaction time when a hard delete occurs. In addition, database pages can be scrubbed during the online checksum process. The pages targeted in this case are as follows:

Deleted records that couldnt be scrubbed during runtime because of dropped tasks if the system is too overloaded or because the store crashed before the tasks got to scrub the data. Deleted tables and secondary indices. When these are deleted, we do not scrub their contents. Therefore, online checksum detects that these pages dont belong to any valid object any longer and it scrubs the pages. For more information about page zeroing in Exchange 2010, see Understanding Exchange 2010 Page Zeroing.

Use performance counters to track the background maintenance tasks

In Exchange Server 2010, events are not recorded for the defragmentation and compaction maintenance tasks. However, you can use performance counters to track the background maintenance tasks. The following table describes the performance counters to use under the MSExchange Database ==> Instances object.

Counter Database Maintenance Duration

Description The number of seconds that have passed since the maintenance started for this database. If the value is 0, maintenance has

been finished for the day. Database Maintenance Pages Bad Checksums Defragmentation Tasks Defragmentation Tasks Completed/sec The number of non-correctable page checksums encountered during a database maintenance pass

The count of background database defragmentation tasks that are currently running The rate at which background database defragmentation tasks are being finished

The following table describes the page zeroing counters to use under the MSExchange Database object:

Counter Database Maintenance Pages Zeroed Database Maintenance Pages Zeroed/sec

Description Indicates the number of pages zeroed by the database engine since the performance counter was invoked Indicates the rate at which pages are zeroed by the database engine

White space
In a database, you can have thousands of tables. You can have at least one table for every folder in every mailbox. The messages tables, folders tables, and attachments tables represent 90 percent of the space that is used in the database. These tables have the greatest percentage of free space (also known as white space) in the database. To determine how much white space exists in a database, and reclaim the white space, follow these steps:

1. Unmount the database. 2. Complete a space dump by using the Exchange Server Database Utilities (Eseutil) tool together with the /MS switch. For more information about how to do this, see How to Run Eseutil /M in File Dump Mode. At the end of the dump file is a line similar to the following: ----------------------------------------------------------------------253 This is a summation of the total number of pages that are available in all the tables. Multiply this value by 32K to determine the true amount of white space in the database. Note: For an example of the Eseutil dump file, see Determining the True Amount of Space in an Exchange Database. After you determine how much white space is in a database, you may also want to reclaim the white space. If you encounter a database that has a significant amount of white space, and you do not expect that the typical operations will reclaim the space, we recommend the following steps:

1. Create a new database and its associated database copies. 2. Move all mailboxes to the new database. 3. Delete the original database and its associated database copies.

See Also
Concepts
New Exchange Core Store Functionality Understanding the Exchange 2010 Store

Other Resources
Microsoft Exchange Server Jetstress 2010

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding the Impact of Named Property and Replica Identifier Limits on Exchange Databases
Applies to: Exchange Server 2010 SP3 Topic Last Modified: 2013-03-07 Microsoft uses the Messaging API (MAPI) to connect different messaging transport components. The MAPI specification presents most objects as properties. To identify these properties, MAPI uses identifiers, known as property identifiers or PropIDs. Property identifiers are a set of hexadecimal values that range from 1 to 0xFFFF. This provides enough values for 65,534 properties. These properties are divided into the following groups, known as ranges:

Transmittable properties Properties that Exchange can send together with a message Internal properties Properties that can be set only by Exchange Non-transmittable properties Properties that are not delivered outside the organization when Exchange delivers a message The properties in these ranges are known as standard properties. Standard MAPI properties have fixed IDs, and represent all properties that are below 0x8000. There is one additional range that is the largest of the groups and which represents all properties that are at 0x8000 and above. The properties in this range are known as named properties. Named properties provide a way for vendors to extend the standard MAPI property set by adding their own properties. Named properties fall into the following main categories:

Properties that have numbers for names These named properties are used by such programs as Microsoft Outlook, and are generally defined in a source file. Properties that have string values for names These named properties are known as "String Named Properties." In addition to a name, each of these properties has an associated GUID. This lets developers divide named properties into property sets. Because named properties do not have specific IDs assigned to them, MAPI provides a facility to dynamically create unique IDs for named properties and to maintain a persistent mapping between a named property and its unique ID. However, the dynamic creation of these IDs means that the property IDs for named properties can vary from computer to computer. The Microsoft Exchange Information Store service maintains a table of named properties for each mailbox. Messages that are sent over the Internet are transferred in a format that is known as Message/RFC822. This is a text format that includes messages in plain text together with headers that contain a set of key-and-value pairs. RFC822 includes support for a set of properties that are called X-headers. When the transport service processes a message that contains custom information, the transport service contacts the information store service to register named properties for X-headers. Note: Any subsequent messages that include the same X-header do not cause Exchange to register additional named properties. Exchange stores these named properties together with the messages that contain the related X-header. Microsoft uses the extensible namespace PS_INTERNET_HEADERS to group the X-headers from messages that were received over the Internet.

Named Properties Limits

The following list summarizes some important points about named properties:

X-headers are fields in Message/RFC822 messages that hold certain important values. Named properties is the method that Exchange uses to reserve an ID for a particular value. After a named property has been allocated, it may not be deallocated. The property remains reserved for the particular name and GUID combination. Because there are a fixed number of named properties available, Exchange uses a quota system to track the number of allocated named properties. In this system, the information store service warns you when available named property IDs are close to becoming exhausted. When a second threshold is reached, the information store service stops allocating named property IDs.

Named Property Exhaustion

Although many programs use named properties, Outlook uses the majority of them. When named property IDs are exhausted, Outlook cannot map a named property. In this scenario, you may experience symptoms that resemble the following:

Event IDs 9666 and 9667 are logged in the Application log. For more information, see Events 9666, 9667, 9668, and 9669 Received When Named Properties or Replica Identifiers Are Depleted for An Exchange Database. Messages that contain properties that cannot be mapped are not delivered. When you examine the message tracking information for an affected message, the information resembles the following:

550 5.2.0 STOREDRV.Deliver: The Microsoft Exchange Information Store service reported an error. The following information should help identify the cause of this error: MapiExceptionNamedPropsQuotaExceeded: 16.18969 When an add-in that adds named properties or X-headers to messages is installed in Outlook, certain messages may not be sent to other users in the organization. In this scenario, the sending user receives a non-delivery report (NDR) that resembles the following:

The message reached the recipient's e-mail system, but delivery was refused. Attempt to resend the message. If it still fails, contact your system administrator. To recover named properties in Microsoft Exchange Server 2010, use the New-MoveRequest cmdlet together with the DoNotPreserveMailboxSignature parameter. For more information, see New-MoveRequest. Note: Doing this depletes the named property IDs by retaining only named properties that exist on at least one message in the mailbox. If all named properties still exist on any message, none will be reclaimed.

Property Changes in Exchange 2010

Exchange Server 2010 includes improvements to address issues that may occur in Microsoft Exchange Server 2007. In Exchange 2010, named property resources are moved to the mailbox level instead of the database level. For more information about the property change issues that may occur in Exchange 2007, see Understanding the Impact of Named Property and Replica Identifier Limits on Exchange Databases.

For More Information

For more information about managing databases, see Managing Storage Groups and Databases.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Exchange Search

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-09-29 With increasing mailbox sizes and increasing amounts of data being stored in mailboxes in the form of messages and attachments, it's crucial for users to be able to quickly search and locate the messages they need. In Microsoft Exchange Server 2010, you can provision personal archives for your users, helping you reduce or eliminate the use of .pst files. This results in more mailbox data being stored by a user, and it makes searching across the user's primary and archive mailboxes an important productivity tool. In Exchange 2010, authorized users can use Multi-Mailbox Search to perform mailbox searches across the entire Exchange 2010 organization for complying with electronic discovery (eDiscovery) requests, regulatory audits, or internal investigations. Multi-Mailbox Search also uses the content indexes created by Exchange Search. Exchange Search is different from full-text indexing available in Exchange Server 2003. Improvements were made to performance, content indexing, and search. New items are indexed almost immediately after they're created or delivered to the mailbox, providing users with a fast, stable, and more reliable way of searching mailbox data. In Exchange 2010 and Exchange Server 2007, content indexing is enabled by default on all mailbox databases, and there's no initial setup or configuration required. Note: Exchange Search doesn't index public folder databases. Contents Content Indexing Exchange Search Performance Exchange Search Clients Advanced Query Syntax Exchange Search and Attachments Improvements Over Exchange Server 2003 Content Indexing Difference Between Exchange Search and Exchange Store Search Exchange Search and Localization Exchange Search and Database Availability Groups

Content Indexing

When Exchange Search services are started, Exchange Search determines the search status of all mailbox databases on the Mailbox server. If a mailbox database is mounted and enabled for search, Exchange Search assigns it one of following status values:

New When the status of a mailbox database is New, Exchange Search creates a content index catalog for the database. After it's created, Exchange Search changes the status of the database to Crawling. Crawling When the status of a mailbox is Crawling, Exchange Search indexes mailboxes in the database. The status remains Crawling until all mailboxes in the database have been indexed. After all mailboxes in the databases have been indexed, Exchange Search changes the status of the database to Notification. Notification After the initial crawl has occurred on a database, Exchange Search is notified by the Exchange store of new events such as message creation, delivery, or deletion. Events are added to the notification queue to be indexed. This happens quickly, so the content index is never more than a few minutes out of date. New messages delivered to a mailbox are indexed within a few seconds of delivery. Return to top

Exchange Search Performance

Exchange Search offers significant performance improvements compared to full-text indexing in Exchange 2003. The search model has changed from a crawl mode to an always up-to-date mode. Several improvements were made to optimize system resources such as CPU, memory, disk input/output (I/O), and disk space required for indexes. These performance improvements result in over 35x improvement in indexing speed. Although a full crawl of the database is much faster, it can use a significant amount of resources on a Mailbox server, depending on the size of the mailbox database. During more intensive phases, this can disrupt mail flow. Because delivery of mail should take precedence over content indexing, a new throttling feature in Exchange Search automatically throttles indexing for a particular mailbox database or set, reducing disk I/O and CPU utilization. Return to top

Exchange Search Clients

Exchange Search provides a service that's consumed by search clients. These clients include Microsoft Outlook, Microsoft Office Outlook Web App, Windows Mobile, the Multi-Mailbox Search feature in Exchange 2010, and Exchange Web Services.

In Outlook 2010 and Office Outlook 2007, Outlook profiles used to configure Outlook features on users' computers can be configured to use Cached Exchange Mode. When Outlook is connected to Exchange in an online mode and accesses the Exchange mailbox, changes such as creation of mailbox items, new mail delivery, and deletion of mailbox items takes place on the Mailbox server. In Cached Exchange Mode, Outlook creates a local replica of the Exchange mailbox on the user's computer. This replica is stored in an .ost file in the user's profile. Changes to mailbox items happen in the local replica, which is then synchronized with the Exchange mailbox. For details about Cached Exchange Mode, see About Cached Exchange Mode. In Cached Exchange Mode, Outlook uses Windows Search, a component built-in in Windows 7 and Windows Vista. Windows Search performs content indexing and provides search functionality to Outlook. Interfacing with a local content indexing and search service provides Outlook users running in Cached Exchange Mode a more efficient way to search their mailbox. In addition to indexing e-mail in the offline store, Windows Search also indexes other data residing in the file system. For details about Windows Search, see Windows Search. Outlook 2010 and Outlook 2007 provide your users an easily accessible Instant Search box located on top of the message list pane, so that users can quickly search mailbox content. Additionally, using the Advanced Find feature, users can create more complex search queries using a number of fields and parameters. Return to top

Advanced Query Syntax

With increasing number of e-mail messages received by users, larger mailboxes, and the resulting information overload, the ability to quickly search messages enhances user productivity, and boosts satisfaction with e-mail. Using Advanced Query Syntax (AQS), users can quickly create advanced search queries and find the messages they need. AQS search queries can be entered directly in the Instant Search box in Outlook. For example, to search messages sent by user April Stewart that have attachments and contain the word Contoso in the subject field, a user can use the following search query: From:"April Stewart" HasAttachments:true Subject:Contoso. To further narrow it to unread messages, the user can add the following keyword and value: unread:true. To further narrow it to messages sent by April last month, the user can add the following keyword and value: Sent:lastmonth. AQS is supported by both Exchange Search on the server and by Windows Search on the desktop. Search queries using AQS work in Outlook 2010 and Outlook 2007 in online and cached modes. In Exchange 2010, users can also use AQS queries in Outlook Web App and Windows Mobile. Exchange Search clients such as Multi-Mailbox Search also support AQS search queries. Outlook 2010 and Outlook 2007 support a large number of AQS keywords. Additionally, Exchange Search also supports the keywords shown in the following table.

Exchange Search keywords

Property Attachments Example attachment:annualreport.pptx Search results Messages that have an attachment named annualreport.pptx. The use of attachment:annualreport or attachment:annual* returns the same results as using the full name of the attachment. Messages with Paul Shen in the Cc field.

Cc

cc:paul shen cc:pauls cc:pauls@contoso.com from:bharat suneja from:bsuneja from:bsuneja@contoso.com retentionpolicy:business critical expires:4/1/2010

From

Messages sent by Bharat Suneja.

Keywords in retention policy

Messages that have the Business Critical retention tag applied.

Date when messages expire according to policy Sent Subject To

Messages that expire on April 1, 2010.

sent:yesterday Subject:"patent filing" to:"ben smith" to:bsmith to:besmith@contoso.com

All messages sent yesterday. All messages where the phrase "patent filing" appears in the Subject field. Messages that have Ben Smith in the To field.

Return to top

Exchange Search and Attachments

Exchange Search indexes text content contained in e-mail attachments. Support for different file formats is provided using search filters. Exchange Setup installs a number of search filters by default, providing support for indexing many popular file formats, including Microsoft Office files. For a list of search filters installed by Exchange Setup, see Default Filters for Exchange Search. You can install additional search filters for file formats that you want Exchange Search to index. Search filters for different file formats are available from many partners and third parties. The following applies to indexing:

Unsearchable items When Exchange Search can't index a file because a search filter for the file format isn't installed on the Mailbox server, the item is treated as an unsearchable item. An item may also be marked as unsearchable due to other reasons. You can retrieve a list of unsearchable items per mailbox, mailbox database, or mailbox server, using the Get-FailedContentIndexDocuments cmdlet. For details, see Diagnose Exchange Search Issues. You can also include unsearchable items when you perform a discovery search using Multi-Mailbox Search. Safe list Certain file types are considered to have no content that can be indexed by Exchange Search. These file types are added to a safe list by creating a null filter value in the registry. Exchange Setup creates a null filter registry value for several file types. Mailbox items containing these file types aren't returned in the list of unsearchable items. For a list of default search filters and default null filter entries, see Default Filters for Exchange Search. Encrypted items Messages encrypted using S/MIME aren't indexed by Exchange Search. Encrypted messages are returned as unsearchable items if you use the

Get-FailedContentIndexDocuments cmdlet. IRM-protected items Messages protected using Information Rights Management (IRM) are indexed by Exchange Search and included in search results. Messages must be protected by using an Active Directory Rights Management Services (AD RMS) server in the same Active Directory forest as the Exchange 2010 Mailbox server. For details, see Information Rights Management. Note: In Cached Exchange Mode, attachments are also indexed by Windows Search. Windows Search uses search filters installed on the user's computer. Return to top

Improvements Over Exchange Server 2003 Content Indexing

The search functionality in Exchange 2003 (content indexing) is replaced with Exchange Search in Exchange 2010. Exchange Search provides the following feature and functionality improvements over content indexing:

Utilization of system resources such as CPU, memory, disk I/O, and disk space required for its indexes is improved, which significantly increases overall performance. New messages are typically indexed within 10 seconds of arrival, and query results are returned within seconds. Exchange Search is automatically enabled upon installation and doesn't require any configuration. Attachments can now be indexed. Several attachment types are supported, including Microsoft Office documents, text attachments, and HTML attachments. Indexing is automatically withheld for a specific mailbox database, which reduces the disk I/O load. Also, indexing is automatically withheld for the entire Mailbox server, which reduces both disk I/O and CPU utilization for Exchange Search. There is an easily accessible search bar in Outlook Web App and query builder support in Outlook 2010 and Outlook 2007. Return to top

Difference Between Exchange Search and Exchange Store Search

Exchange Search allows you to quickly search text in messages through the use of pre-built indexes. Exchange store search is based on a sequential scan of all the messages in the search scope instead of using the pre-built indexes The following table compares some of the differences between Exchange Search and Exchange store search.

Exchange Search vs. Exchange store search

Exchange Search Faster Searches the content index created by crawling the mailbox database Indexes new items within seconds of creation or delivery to a mailbox Uses words, phrases, and sentences, ignores punctuation and spaces, not case-sensitive Supports only prefix searches, doesn't support substring matches Searches attachments using available search filters Can search messages in different languages Return to top Exchange store search Slower Searches the store May not return newer items Searches stream of bytes, finds only exact matches Supports substring matches Doesn't search within attachments Not language-aware

Exchange Search and Localization

Localization support for Exchange Search is limited to scenarios in which the client locale matches the message locale (which must also match the language used in the message body). Exchange Search doesn't support instances where a single message has multiple languages embedded in the body or where the client locale is different from the message locale. To get consistent results for localized searches, the following must be true:

An e-mail message must be written in a single language and that language must match the locale of the message. The search expression must be in a single language. The language must match the locale of the client computer, as identified by the connection to the server. Return to top

Exchange Search and Database Availability Groups

In organizations that have a database availability group (DAG), during the seeding process, DAG members with a passive mailbox database copy replicate the content index catalog from the DAG member that has the active mailbox database copy. The content index is typically 10 percent the size of the mailbox database. After initial seeding, the server with the passive database copy gets message data from the server with the active database and performs content indexing locally. The bandwidth used for copying message content for indexing is in addition to the bandwidth used for replication of transaction logs. When planning a high availability deployment, you must consider the bandwidth used by Exchange Search.

The Exchange 2010 Mailbox Server Role Requirements Calculator includes content indexing considerations when calculating the bandwidth required for content indexing in a DAG. For more information about the calculator, including a link to download the calculator, see the Exchange Server Team Blog article Exchange 2010 Mailbox Server Role Requirements Calculator. To learn more about DAGs, see Understanding Database Availability Groups.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Hierarchical Address Books

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-09-30 The hierarchical address book (HAB) is a feature in Microsoft Exchange Server 2010 and the Microsoft Outlook 2010 address book that enables end users to browse for recipients in their Exchange organization using an organizational hierarchy. In most Exchange 2010 deployments, users are limited to the default global address list (GAL) and its associated recipient properties. Additionally, the structure of the GAL often doesn't accurately reflect the management or seniority relationships among recipients in your organization. Being able to customize an HAB that maps to your organization's unique business structure provides your users with an efficient method for locating internal recipients.

Using Hierarchical Address Books

In an HAB, your root organization (for example, Contoso, Ltd) is used as the top-level tier. Under this top-level tier, you can add several child tiers to create a customized HAB that's segmented by division, department, or any other organizational tier you want to specify. The following figure illustrates an HAB for Contoso, Ltd with the following structure:

The top-level tier represents the root organization Contoso, Ltd. The second-level child tiers represent the business divisions within Contoso, Ltd: Corporate Office, Product Support Organization, and Sales & Marketing Organization. The third-level child tiers represent departments within the Corporate Office division: Human Resources, Accounting Group, and Administration Group.

You can provide an additional level of hierarchical structure by using the SeniorityIndex parameter. When creating an HAB, use the SeniorityIndex parameter to rank individual recipients or organizational groups by seniority within these organizational tiers. This ranking specifies the order in which the recipients or groups are displayed in the HAB. For example, in the preceding example, the SeniorityIndex parameter for the recipients in the Corporate Office division is set to the following:

100 for David Hamilton 50 for Rajesh M. Patel 25 for Amy Alberts Note: If the SeniorityIndex parameter isn't set or is equal for two or more users, the HAB sorting order uses the PhoneticDisplayName parameter value to list the users in ascending alphabetical order. If the PhoneticDisplayName parameter value isn't set, the HAB sorting order defaults to the DisplayName parameter value and lists the users in ascending alphabetical order.

Configuring Hierarchical Address Books

Detailed instructions for creating HABs are included in the topic Configure Hierarchical Address Books. The general steps are as follows:

1. Create a distribution group that will be used for the root organization (top-level tier). If desired, you can use an existing organizational unit in your Exchange forest for the distribution group. 2. Create distribution groups for the child tiers and designate them as members of the HAB. Modify the SeniorityIndex parameter of these groups so they're listed in the proper hierarchical order within the root organization. 3. Add organization members. Modify the SeniorityIndex parameter of the members so they're listed in the proper hierarchical order within the child tiers. 4. For accessibility purposes, you can use the PhoneticDisplayName parameter, which specifies a phonetic pronunciation of the DisplayName parameter. To learn more about the PhoneticDisplayName parameter and speech recognition, see Understanding Automatic Speech Recognition Directory Lookups.

2010 Microsoft Corporation. All rights reserved.

 2013 Microsoft. All rights reserved.

Understanding Mailbox Import and Export Requests

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-04-28 Microsoft Exchange Server 2010 Service Pack 1 (SP1) introduces a new method for importing and exporting mailboxes. Using the MailboxImportRequest or MailboxExportRequest cmdlet sets, you can import data from or export data to .pst files. After you initiate a mailbox import or export request, the process is completed asynchronously by the Microsoft Exchange Mailbox Replication service (MRS). MRS resides on all Exchange 2010 Client Access servers and is the service responsible for moving mailboxes, importing and exporting .pst files, and restoring disabled and soft-deleted mailboxes. For information about how to perform mailbox import and export requests, see Managing Mailbox Import and Export Requests. Contents Reasons to Import or Export Mailbox Data Limitations to Importing and Exporting Mailbox Data in Previous Versions of Exchange Advantages to Using Import and Export Requests Permissions Considerations Importing Mailbox Data Exporting Mailbox Data

Reasons to Import or Export Mailbox Data

There are several reasons why you may want to import or export mailbox data:

Satisfy compliance requirements You can export mailbox content to a .pst file for legal discovery purposes. After the export is complete, you can import the content to a mailbox used specifically for compliance purposes. Create a point-in-time snapshot of a mailbox By creating a snapshot of specific mailboxes, you avoid having to retain an entire backup set for a mailbox database. Move a user's .pst file into his or her mailbox or personal archive Microsoft Outlook users can save their e-mail locally as .pst files. Using the NewMailboxImportRequest cmdlet, you can move data from a user's .pst file to his or her mailbox or personal archive. This is an easy method for transferring email from a user's local computer to Exchange servers. To learn more, see Understanding Personal Archives. Return to top

Limitations to Importing and Exporting Mailbox Data in Previous Versions of Exchange

Exchange Server 2007 and the release to manufacturing (RTM) version of Exchange 2010 use the Import-Mailbox and Export-Mailbox cmdlets to import and export .pst files. There are limitations to using these cmdlets:

You must install Outlook on an Exchange server dedicated to importing and exporting mailbox data. As a result, you must purchase both an Exchange and an Outlook license solely for this purpose. The .pst file must reside on the server dedicated to importing and exporting mailbox data. The import or export operation is performed by the related cmdlet, and content in the .pst file moves through the dedicated server. Therefore, you can't shut down the session until the import or export is complete. Return to top

Advantages to Using Import and Export Requests

The following are advantages to using import and export requests in Exchange 2010 SP1:

A .pst provider is included in Exchange 2010 SP1 that can read and write .pst files. Import and export requests are asynchronous. The process is performed by MRS, which takes advantage of the queuing and throttling frameworks. The .pst files can be imported directly to a user's personal archive. Multiple .pst files can be imported or exported at the same time. Import and export cmdlets can be run against any Exchange 2010 SP1 server in your organization. The .pst files can reside on any shared network drive accessible by your Exchange servers. The following types of .pst files are supported by Exchange 2010 SP1: Unicode and ANSI files created by Office Outlook 2003 Unicode files created by Office Outlook 2007 and Outlook 2010 Unicode files created by the Exchange 2010 SP1 New-MailboxExportRequest cmdlet ANSI files created by the Exchange Server Mailbox Merge wizard (ExMerge)

Return to top

Permissions
You must have the correct permissions to import or export mailbox data. By default, none of the role groups include the Mailbox Import Export role. You must add the Mailbox Import Export role to a role group. If you try to run the import or export cmdlets without the correct permissions, you receive an error stating that the cmdlet doesn't exist. For details, see Add the Mailbox Import Export Role to a Role Group. Note: After you add the Mailbox Import Export role to a role group, you must restart the Exchange Management Shell. Return to top

Considerations
Before you import or export mailbox data, consider the following:

To import or export mailbox data, a network shared folder accessible by your Exchange servers must be set up. You must also grant read/write permissions to the Exchange Trusted Subsystem group so that group can access the network share where you import and export mailbox data. If you don't grant this permission, you receive an error message stating that Exchange is unable to establish a connection to the target mailbox. The maximum .pst file size supported by Outlook is 50 gigabytes (GB). Therefore, we recommend that you don't import a .pst file larger than 50 GB. You can create multiple .pst files for mailboxes larger than 50 GB by specifying specific folders to include or exclude or by using a content filter. Import and export requests are performed by MRS, which also processes move requests and mailbox restore requests. All requests are queued and throttled by MRS. To learn more, see Throttling the Mailbox Replication Service. Importing and exporting mailbox data may take several hours depending on file size, network bandwidth, and MRS throttling. Data can't be imported to a public folder or public folder database. Return to top

Importing Mailbox Data

Use the MailboxImportRequest cmdlet set to import data from a .pst file to a mailbox or personal archive. The following is a list of options you can specify when importing mailbox data from a .pst file: Note: The mailbox to which you import the data must exist. You can't import data to a user account that doesn't have a mailbox. You can import data to a different user account than the one from which it was exported. For example, you can export data from john@contoso.com and import it to legaldiscovery@contoso.com. You can import items to only the user's personal archive by specifying the IsArchive parameter. If associated folder messages exist in the .pst file, you can import them using the AssociatedMessagesCopyOption parameter. Associated messages contain hidden data with information about rules, views, and forms. If they exist in the .pst file, all messages from the transport dumpster are imported. You can include or exclude specific folders using the IncludeFolders or ExcludeFolders parameter. You can exclude the Recoverable Items folder using the ExcludeDumpster parameter. By default, an import request includes the user's Recoverable Items folder if it's present in the .pst file.

MailboxImportRequest Cmdlet Set

Use the following cmdlets for mailbox import requests.

Cmdlet New-MailboxImportRequest

Description Start the process of importing a .pst file to a mailbox or personal archive. You can create more than one import request per mailbox. Each request must have a unique name. Change import request options after the request is created or recover from a failed request.

Topic Create a Mailbox Import Request Configure Mailbox Import Request Properties Suspend a Mailbox Import Request Resume a Mailbox Import Request Remove a Mailbox Import Request View Mailbox Import Request Properties

Set-MailboxImportRequest

SuspendMailboxImportRequest ResumeMailboxImportRequest RemoveMailboxImportRequest Get-MailboxImportRequest

Suspend an import request any time after the request is created but before the request reaches the status of Completed. Resume an import request that's suspended or failed.

Remove fully or partially completed import requests. Completed import requests aren't automatically cleared. You must use this cmdlet to remove them. View general information about an import request.

GetMailboxImportRequestStatistics Return to top

View detailed information about an import request.

View Mailbox Import Request Properties

Exporting Mailbox Data

Use the MailboxExportRequest cmdlet set to export mailbox data to a .pst file. You can export one mailbox or several mailboxes, but only one request is written to each .pst file at a time. The following is a list of options you can specify when exporting mailbox data to a .pst file:

You can export personal archive data using the IsArchive parameter. You can filter the messages that are exported using the ContentFilter parameter. You can filter by message content, attachment, senders, recipients, Inbox category, importance, message type, message size, and when the message was sent, received, or expired. For more information, see Filterable Properties for the -ContentFilter Parameter. You can specify folders to include or exclude using the IncludeFolders or ExcludeFolders parameter. If exporting data from an Exchange 2010 mailbox, you can also exclude the Recoverable Items folder using the ExcludeDumpster parameter. You can export associated messages using the AssociatedMessagesCopyOption parameter. Associated messages contain hidden data with information about rules, views, and forms. By default, associated items aren't copied to the .pst file.

MailboxExportRequest Cmdlet Set

Use the following cmdlets for mailbox export requests.

Cmdlet New-MailboxExportRequest

Description Start the process of exporting data from a primary mailbox or personal archive to a .pst file. You can create more than one export request per mailbox. Each request must have a unique name. Change export request options after the request is created or recover from a failed request.

Topic Create a Mailbox Export Request Configure Mailbox Export Request Properties Suspend a Mailbox Export Request Resume a Mailbox Export Request Remove a Mailbox Export Request View Mailbox Export Request Properties View Mailbox Export Request Properties

Set-MailboxExportRequest

SuspendMailboxExportRequest ResumeMailboxExportRequest RemoveMailboxExportRequest Get-MailboxExportRequest

Suspend an export request any time after the request is created but before the request reaches the status of Completed. Resume an export request that's suspended or failed.

Remove fully or partially completed export requests. Completed export requests aren't automatically cleared. You must use this cmdlet to remove them. View general information about an export request.

GetMailboxExportRequestStatistics Return to top

View detailed information about an export request.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Move Requests

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-02-28 When you move a mailbox, you're moving it from a source mailbox database to a target mailbox database. The target mailbox database can be on the same server, on a different server, in a different domain, in a different Active Directory site, or in another forest. Note: This topic doesn't cover moving mailboxes to or from Microsoft Office Outlook Web App. Contents Cautions Changes in Exchange 2010 SP1 Limitations to Moving Mailboxes in Previous Versions of Exchange Advantages of Move Requests Reasons for Moving Mailboxes Supported Scenarios for Moving Mailboxes Services Used in Move Requests Basic Move Request Process Remote Mailbox Moves Mailbox Moves Using a Script Soft-Deleted Mailboxes Personal Archives Shared Mailboxes and Resource Mailboxes Mailbox Moves During Server Failures Client Experience Looking for management tasks related to move requests? See Managing Move Requests.

Cautions
When moving mailboxes, consider the following:

You can't use the Exchange System Manager or Active Directory Users and Computers to move mailboxes from Microsoft Exchange Server 2003 to Exchange Server 2010. You can't use the Move-Mailbox cmdlet in Exchange Server 2007 to move mailboxes from Exchange 2007 to Exchange 2010. When you move mailboxes, users won't be able to view their message tracking information. Return to top

Changes in Exchange 2010 SP1

The following changes were made to move request functionality in Exchange 2010 Service Pack 1 (SP1):

Exchange 2010 SP1 now soft deletes the mailbox on the source database, so that you can recover the mailbox in the event of a Mailbox server failover or data loss. You can restore a soft-deleted mailbox by using the MailboxRestoreRequest cmdlet set. To learn more, see Soft-Deleted Mailboxes later in this topic. Note: Soft-deleted mailboxes require that both the source Mailbox server and the Client Access server performing the request be running Exchange 2010 SP1. The MoveRequest cmdlet set has been updated to support moving archives to a separate database. Return to top

Limitations to Moving Mailboxes in Previous Versions of Exchange

Exchange 2007 uses the Move-Mailbox cmdlet to move mailboxes between mailbox databases. There are limitations to using this cmdlet:

Mailbox moves are offline. While you move a mailbox, which can take several hours, the user can't access the mailbox. Moving mailboxes is synchronous. The cmdlet does the actual move, and you can't close the Exchange Management Shell session while the move is being performed. The Dumpster folder isn't moved with the mailbox. Content indexing doesn't begin until after the move is completed. This results in a poor search experience for users until the indexing is completed. Move throttling is manually controlled by administrators. Moving mailboxes across forests requires direct access to Active Directory and the mailbox database. Return to top

Advantages of Move Requests

Move requests are a new feature in Exchange 2010. There are multiple advantages to using move requests:

Mailbox moves are asynchronous and are performed by the Microsoft Exchange Mailbox Replication service (MRS). To learn more, see Asynchronous Mailbox Moves later in this section. Mailboxes are kept online during the asynchronous moves. To learn more, see Online Mailbox Moves later in this section. The items in a mailbox's Recoverable Items folder are moved with the mailbox. Note: The Recoverable Items folder is available only in Exchange 2010. To learn more, see Understanding Recoverable Items. As soon as the mailbox move begins, content indexing starts to scan the mailbox so that fast searching is available upon completion of the move. You can configure throttling for each MRS instance, each mailbox database, or each Mailbox server. Remote mailbox moves work over the Internet by way of the Microsoft Exchange Mailbox Replication Proxy (MRSProxy) service. You don't need to set up a direct back-end server and Active Directory access between the forests. Mailbox moves can be managed from any Exchange 2010 server within the organization. Mailbox content doesn't move through an administrative computer. For example, in Exchange 2007, when you run the Move-Mailbox cmdlet, the data move is managed by the computer on which you run the cmdlet. You can't shut down that session of Exchange until the move completes. The mailbox's move history is maintained in the mailbox.

Asynchronous Mailbox Moves

Using the move request cmdlets in Exchange 2010, you can perform an asynchronous move because the cmdlets don't perform the actual move. The move is performed by MRS, a service that runs on all Client Access servers in your Exchange 2010 organization. Using MRS is beneficial because you can manage mailbox moves from any Exchange 2010 server within your organization after the move request is started. For more information, see Microsoft Exchange Mailbox Replication Service later in this topic.

Online Mailbox Moves

In an online mailbox move, end users can still access their e-mail accounts during the move. The user is only locked out of the account for a brief time at the end of the process (when the final synchronization occurs). Online mailbox moves are supported between Exchange 2010 databases and between Exchange 2007 SP3 and Exchange 2010 databases. You can perform online mailbox moves across forests or in the same forest. The process for local mailbox moves and remote mailbox moves is different from online moves and is discussed later in this topic. Return to top

Reasons for Moving Mailboxes

You may need to move mailboxes in the following scenarios:

Transition When you transition an existing Exchange 2007 or Exchange Server 2003 organization to Exchange 2010, you move mailboxes from the existing Exchange servers to an Exchange 2010 Mailbox server. Realignment You can move mailboxes for realignment purposes. For example, you may want to move a mailbox from one database to a database that has a larger mailbox size limit. Investigating an issue If you need to investigate an issue with a mailbox, you can move that mailbox to a different server. For example, you can move all mailboxes that have high activity to another server. Corrupted mailboxes If you encounter corrupted mailboxes, you can move the mailboxes to a different server or database. The corrupted messages won't be moved. Physical location changes You can move mailboxes to a server in a different Active Directory site. For example, if a user moves to a different physical location, you can move that user's mailbox to a server closer to the new location. Separation of administrative roles You may want to separate Exchange administration from Windows operating system account administration. To do this, you can move mailboxes from a single forest into a resource forest scenario. In this scenario, the Exchange mailboxes reside in one forest and their associated Windows user accounts reside in a separate forest. Outsourcing e-mail administration You may want to outsource the administration of e-mail and retain the administration of Windows user accounts. To do this, you can move mailboxes from a single forest into a resource forest scenario. Integrating e-mail and user account administration You may want to change from a separated or outsourced e-mail administration model to a model in which e-mail and user accounts can be managed from within the same forest. To do this, you can move mailboxes from a resource forest scenario to a single forest. In this scenario, the Exchange mailboxes and Windows user accounts reside in the same forest. Return to top

Supported Scenarios for Moving Mailboxes

The following table lists the supported scenarios for moving Exchange mailboxes and includes links to related topics.

Supported scenarios for moving mailboxes

Moving from Exchange 2010 Exchange 2007 SP3 Exchange 2007 SP1 Exchange 2003 SP2 Exchange 2010 Exchange 2010 Exchange 2000 Exchange 2010 Return to top Moving to Exchange 2010 Exchange 2010 Exchange 2010 Exchange 2010 Exchange 2007 SP3 Exchange 2003 SP2 Exchange 2010 Exchange 2000 Supported Yes Yes No Yes Yes Yes No No Online move supported Yes Yes No No No No No No Related topic Managing Move Requests Move Mailboxes from Exchange 2007 Servers to Exchange 2010 Servers Move Mailboxes from Exchange 2007 Servers to Exchange 2010 Servers Move Mailboxes from Exchange 2003 Servers to Exchange 2010 Servers Move Mailboxes from Exchange 2010 Servers to Exchange 2007 Servers Move Mailboxes from Exchange 2010 Servers to Exchange 2003 Servers Not applicable Not applicable

Services Used in Move Requests

Move requests are processed by two services:

Microsoft Exchange Mailbox Replication service (MRS) Microsoft Exchange Mailbox Replication Proxy (MRSProxy) service

Microsoft Exchange Mailbox Replication Service

When you use the move request cmdlets to move mailboxes, MRS processes the move process. As stated earlier, MRS resides on an Exchange 2010 Client Access server and is the service that moves mailboxes from the source database to the target database. In Exchange 2007, the mailbox move is performed by the MoveMailbox cmdlet. By using a service as the agent of the move, mailboxes can be moved while simultaneously remaining accessible to users. During the move, you can view, cancel, and manage the move request from any Exchange 2010 server in your organization. You can start and stop MRS as you would any service. MRS constantly checks for all move requests in its own Active Directory site. In addition, there's a sharing mechanism between all instances of MRS so that no two servers will attempt to perform the same move request. All MRS instances in an Active Directory site work together so that database and Client Access server throttling is handled across all instances of MRS. MRS throttling is controlled by a configuration file. For more information about how to modify the configuration file, see Throttling the Mailbox Replication Service.

Microsoft Exchange Mailbox Replication Proxy Service

In addition to MRS, the MRSProxy service is installed on every Exchange 2010 Client Access server. MRSProxy helps to facilitate cross-forest move requests and runs on the remote forest's Exchange 2010 Client Access server. However, MRSProxy is disabled by default. You need to turn on the MRSProxy service on the remote forest. We recommend that you enable MRSProxy on all Client Access servers in the remote forest. For more information, see Start the MRSProxy Service on a Remote Client Access Server. Return to top

Basic Move Request Process

The following figure illustrates the basic process for local move requests.

In this scenario, Ayla's mailbox will be moved from the source database DB01 on Mailbox server MBX02 to the target database DB02 on Mailbox server MBX01. To do this, you run the following command.

New-MoveRequest -Identity Ayla@contoso.com -TargetDatabase "DB02"

The following steps describe the basic process for local move requests:

1. The command updates Active Directory, and then places a special message in the system mailbox within that Active Directory site that a move request has been initiated and is set to a status of Queued. Information about the move request is stored in two places: the target database's system mailbox and in Active Directory. If the move is an offline move, the mailbox is locked and can't be accessed until the move reaches a status of Completed. 2. All instances of MRS periodically check the system mailbox on every database in its Active Directory site to verify if there are any queued move requests. In this example, the MRS instance on CAS01 finds Ayla's mailbox in the Queued status. Note: The New-MoveRequest cmdlet selects an instance of MRS and requests that the service process the move request immediately. If the selected instance of MRS is available, it starts the move immediately. If not, the mailbox remains in the Queued status until an MRS instance finds the move request. 3. MRS begins to move the data from DB01 to DB02. MRS updates the mailbox's status in the system mailbox to In Progress. 4. When the move is almost finished, Ayla's mailbox is locked for a short time while the final mailbox synchronization is completed. At this point, the move request status changes to Completion In Progress. 5. When the move is complete, Ayla's new mailbox on DB02 is activated, and the old mailbox on DB01 is soft deleted. The move request status changes to Completed. Depending on Ayla's e-mail client, she may need to log off and log on again to access her mailbox. For more information, see Client Experience later in this topic. 6. The administrator clears the move request information from Active Directory and on the system mailbox on DB02. Until the move request information is cleared, you can't move the mailbox again. For details about how to clear a move request, see Clear or Remove Move Requests. A record of the move is kept in Ayla's mailbox and can be accessed by running the Get-MailboxStatistics cmdlet with the IncludeMoveReport parameter. For more information, see View Move Request Properties. Return to top

Remote Mailbox Moves

Remote mailbox moves are also known as cross-forest mailbox moves. Exchange 2010 supports two types of remote mailbox moves:

Remote mailbox moves that have Exchange 2010 in both forests In this scenario, one forest is an Exchange 2010 forest, and the other forest has at least one Exchange 2010 Client Access server. You can use the Exchange Management Console (EMC) or the Exchange Management Shell to perform these mailbox moves. For details, see Create a Remote Move Request That has Exchange 2010 in Both Forests. Remote mailbox moves with a legacy Exchange forest In this scenario, one forest contains Exchange 2010, and the other forest contains Exchange 2003 SP2, Exchange 2007 SP3, or a combination of both. No Exchange 2010 Client Access server is installed in the legacy forest. You can't use the EMC to perform these mailbox moves. You must use the Shell. For details, see Create a Remote Legacy Move Request Where One of the Forests Doesn't Have Exchange 2010.

Prerequisites for Moving Mailboxes Across Forests

The prerequisites for moving mailboxes across forests are extensive. For details, see Prepare Mailboxes for Cross-Forest Move Requests.

Using the TargetDatabase or the RemoteTargetDatabase Parameters

The New-MoveRequest cmdlet uses the TargetDatabase and the RemoteTargetDatabase parameters to identify the target database to which you're moving mailboxes.

TargetDatabase Parameter
The TargetDatabase parameter specifies the identity of the database to which you're moving the mailbox. Use this parameter to perform local and remote mailbox moves when initiating the move from the target forest. When you initiate the move from the source forest, MRS pulls the mailbox from the source forest to the target forest. Note: Using the TargetDatabase parameter is optional. If you don't specify this parameter, its usage is implied, and the mailbox provisioning load balancer specifies a target database. If you don't want the load balancer to select a database, either use the TargetDatabase parameter or specify the databases you want to exclude from provisioning by setting the IsExcludedFromProvisioning parameter to $true in the Set-MailboxDatabase cmdlet.

RemoteTargetDatabase Parameter
The RemoteTargetDatabase parameter specifies the identity of the target database in the remote forest. Use this parameter for remote mailbox moves only when you need to initiate the move from the source forest. For example, if you're moving a mailbox from an Exchange 2010 server to an Exchange 2007 or Exchange 2003 server, you initiate the move from the Exchange 2010 forest, which is the source forest. When you initiate a move from the source forest, MRS pushes the mailbox from the Exchange 2010 server to the Exchange 2007 or Exchange 2003 server. This example pushes Tony Smith's mailbox to the remote forest.

New-MoveRequest -Identity 'tony@humongousinsurance.com' -RemoteLegacy -RemoteTargetDatabase DB03 -RemoteGlobalCatalog 'GC01.humongousinsurance.co

Remote Mailbox Moves with Exchange 2010 in Both Forests

The following describes a remote mailbox move scenario:

One forest is an Exchange 2010 forest and the other forest has at least one Exchange 2010 Client Access server. MRS and MRSProxy exist on all Exchange 2010 Client Access servers. MRS processes the cross-forest moves. The Fourth Coffee and Contoso forests both contain Exchange 2010 Client Access servers, but only Contoso contains Exchange 2010 Mailbox servers. Fourth Coffee contains only Exchange 2007 SP3 Mailbox servers. Fourth Coffee contains the mailbox for tony@fourthcoffee.com. Contoso contains a mail-enabled user for tony@fourthcoffee.com that has all the prerequisite settings configured. The following command is run from the target forest, Contoso.com.

New-MoveRequest -Identity 'tony@fourthcoffee.com' -TargetDatabase DBa

-RemoteHostName 'CAS01.fourthcofee.com' -RemoteCredential (Get-Credent

Note: If Tony's mailbox were being moved from an Exchange 2003 server, the move would be offline, and Tony wouldn't be able to access his mailbox until the move was complete. The following figure illustrates this remote mailbox move scenario.

1. The New-MoveRequest cmdlet prompts MRS on the Client Access server in the Contoso forest. The cmdlet updates the Contoso Active Directory information and the system mailbox on the target database. At this point, the move request status is Queued. 2. To initiate the move, MRS in the Contoso forest communicates through MRSProxy in the Fourth Coffee forest. MRSProxy then updates the Fourth Coffee Active Directory information and the system mailbox on the remote database. At this point, the status changes to In Progress. 3. The MRS server in the Contoso forest pulls Tony's mailbox data from the Mailbox server through the MRSProxy server in Fourth Coffee to the mail-enabled user tony@fourthcoffee.com. At this point, the status is In Progress. 4. When the mailbox move is almost complete, MRSProxy locks Tony's mailbox at Fourth Coffee for a short time while final synchronization is completed. At this point, the status is Completion In Progress. 5. In the Contoso forest, MRS converts the mail-enabled user tony@fourthcoffee.com to the mailbox tony@contoso.com. In the Fourth Coffee forest, MRSProxy converts the mailbox tony@fourthcoffee.com to the mail-enabled user tony@contoso.com, and the mailbox is soft deleted. At this point, the status is Completed. Tony can now access his mailbox in the Contoso forest. Depending on Tony's e-mail client, he may need to log off and log on again to access his mailbox. For more information, see Client Experience later in this topic. 6. The administrator clears the move request information from Active Directory and from the system mailbox. Until the move request information is cleared, you can't move the mailbox again. For details about how to clear a move request, see Clear or Remove Move Requests. A record of the move is kept in Tony's mailbox and can be accessed by running the Get-MailboxStatistics cmdlet with the IncludeMoveReport parameter. Note: If you want to move the mailbox back to the remote forest, you must initiate the move in the Contoso forest. This is because the Contoso Mailbox server is running the latest version of Exchange (in this case, Exchange 2010). In addition, you must use the RemoteTargetDatabase parameter when you run the NewMoveRequest cmdlet.

Remote Legacy Mailbox Moves

If you're moving mailboxes remotely to or from Exchange 2007 or Exchange 2003 organizations, and those organizations don't contain an Exchange 2010 Client Access server, MRS in the Exchange 2010 forest will directly access the remote legacy database and the remote organization's Active Directory server. When performing a remote legacy move request, you must supply the following information in the command:

Identity of the mail-enabled user RemoteLegacy switch Fully qualified domain name (FQDN) of the remote global catalog server FQDN of the external e-mail address created in the source forest for the mail-enabled user when the move request is complete Target database when moving mailboxes to Exchange 2010 or the remote target database when moving mailboxes from Exchange 2010 to the remote legacy database The following describes a remote legacy mailbox move scenario:

The legacy forest (Humongous Insurance) doesn't contain an Exchange 2010 Client Access server. This scenario is similar to the remote move request process. However, because the remote legacy forest doesn't have an instance of MRSProxy to connect with, MRS in the Contoso forest connects directly to the Humongous Insurance Active Directory server and system mailbox on the Exchange 2003 mailbox database. When you move Exchange 2003 mailboxes to Exchange 2010, the mailbox move will be offline. During the move, the users won't be able to access their mailboxes. When you move Exchange 2007 SP3 to Exchange 2010 mailboxes, the move will be online, and the users can access their mailboxes during the move. The following command is run from the target forest, Contoso.com.

New-MoveRequest -Identity 'tony@humongousinsurance.com' -RemoteLegacy -TargetDatabase DB02 -RemoteGlobalCatalog 'GC01.humongousinsurance.com' -RemoteCredential $Cred -TargetDeliveryDomain 'mail.contoso.com'

The following figure illustrates this remote legacy mailbox move scenario.

Return to top

Mailbox Moves Using a Script

The MoveMailbox.ps1 script in Exchange 2010 provides a synchronous mailbox move management experience similar to the Exchange 2007 Move-Mailbox cmdlet. By default, scripts are installed at C:\Program Files\Microsoft\Exchange Server\V14\Scripts. For more information, see Move Mailboxes by Using the MoveMailbox.ps1 Script in the Shell. Note: You can use this script for local moves only. You can't use this script for cross-forest moves. MoveMailbox.ps1 performs the following tasks:

1. Creates a local move request. 2. Waits for the mailbox move to complete. 3. Removes the move request after it's complete. Return to top

Soft-Deleted Mailboxes
When mailboxes are moved from an Exchange 2010 SP1 database to any other database, Exchange doesn't fully delete the mailbox from the source database immediately upon completion of the move. Instead, the mailbox in the source mailbox database is switched to a soft-deleted state. Mailbox data can be accessed during a mailbox restore operation using the MailboxRestoreRequest cmdlet set. The soft-deleted mailboxes are retained in the source database until either the deleted mailbox retention period expires or you use the Remove-StoreMailbox cmdlet to purge the mailbox. Note: Soft-deleted mailboxes require that both the source Mailbox server and the Client Access server performing the request be running Exchange 2010 SP1. To view soft-deleted mailboxes, run the Get-MailboxStatistics cmdlet against a database and look for results that have a DisconnectReason property with a value of SoftDeleted.

Personal Archives
In the release to manufacturing (RTM) version of Exchange 2010, if a personal archive exists for a mailbox that you want to move, the archive gets moved with the primary mailbox. This is because the personal archive and the primary mailbox must reside on the same mailbox database. Before moving mailboxes that have a personal archive, you should consider the size of the archive. Consider database size and how that size might impact the time the move will take to complete. In Exchange 2010 SP1, personal archives and mailboxes can exist on separate databases. The move request cmdlets and the move request user interface (UI) in the EMC support moving mailboxes and personal archives together or separately. By default, the primary mailbox and the archive are moved together. For more information about moving an archive and primary mailbox separately, see Create a Local Move Request. If you're moving mailboxes from an Exchange 2010 server to an Exchange 2007 or Exchange 2003 server, you must first disable the personal archive before you can move the mailbox. For details, see Disable a Personal (On-Premises) or Cloud-Based Archive for a Mailbox. To learn more about personal archives, see Understanding Personal Archives. Return to top

Shared Mailboxes and Resource Mailboxes

In addition to the default user mailboxes, you can move shared mailboxes and resource mailboxes. A shared mailbox is a mailbox to which multiple users can log on. A resource mailbox is a mailbox that represents a type of resource, such as a conference room or video equipment. Resource mailboxes have additional properties in Active Directory that user mailboxes and shared mailboxes don't have, such as capacity. Exchange 2003 doesn't support resource mailboxes. Instead, you must use shared mailboxes to represent resources. If you move a shared mailbox from Exchange 2003 to Exchange 2010, MRS creates the mailbox as a shared Exchange 2010 mailbox. After you move the mailbox to Exchange 2010, you can convert it to a resource mailbox. For details about how to convert a shared mailbox to a resource mailbox, see Convert a Mailbox. Return to top

Mailbox Moves During Server Failures

Move requests can handle transient errors. MRS conducts checkpoints every 5 minutes to make sure that the database to which the mailbox being moved is still operational. If MRS finds that the target database isn't operational, MRS will pause for 30 seconds, and then retry the move. If you experience a failover, the move won't fail. Instead, MRS will detect a database failover, determine the new location of the database, and then restart the move process. Another error that could occur is if the Client Access server on which MRS is running stops responding. If this happens, the move stops, and one of the other MRS instances will continue the process and complete the move. For more information, see Troubleshooting Mailbox Moves. Return to top

Client Experience
The following table lists the different experiences end users will have, based on the version of Exchange that their mailbox is being moved to and from, and based on which client application they're using when the move request begins.

Client experience based on Exchange version and client application

Moving from Moving to Client application being used when the move starts Microsoft Outlook 2010, Office Outlook 2007, or Office Outlook 2003 Outlook Web App End-user experience

Exchange 2010 or Exchange 2007 SP2 Exchange 2010

Exchange 2010

When the move request has a status of Completion in Progress, the mailbox will be locked for a short time. When the move is complete, Outlook displays a message notifying the user to close and restart Outlook.

Exchange 2010

When the move request has a status of Completion in Progress, the mailbox is locked for a short time. If users are logged on to Outlook Web App when the mailbox is locked, or if they attempt to log on while the mailbox is locked, they will receive an error stating that the mailbox is being moved, and they won't be able to log on until the move is complete. If users aren't logged on at the time, they won't be aware of the move unless the URL that they use to access Outlook Web App changed. If the URL changed, users receive a message similar to the following: "Use the following link to open this mailbox with the best performance: https://mail.contoso.com/owa" When users click the link, they are directed to the new location and can log on using their credentials. When the move request has a status of Completion in Progress, the mailbox is locked for a short time. If users are logged on to Outlook Web Access when the mailbox is locked, they are automatically logged off and need to log on again to view their mailbox. If users aren't logged on at the time, they won't be aware of the move unless the URL that they use to access Outlook Web Access changed. If it changed, users receive a message similar to the following: "Use the following link to open this mailbox with the best performance: https://mail.contoso.com/owa" When users click the link, they are directed to the new location and can log on using their credentials. When the move request has a status of Completion in Progress, the mailbox is locked for a short time. Users experience an interruption only if the Outlook Web App URL that they use has changed. If the URL has changed, users must modify the URL in their phone's e-mail settings.

Exchange 2007 SP3

Exchange 2010

Microsoft Outlook Web Access

Exchange 2010 or Exchange 2007 SP3 Exchange 2010 or Exchange 2007 SP3 Exchange 2003 SP2 or SP3 Exchange 2003 SP2

Exchange 2010

Outlook Mobile Access

Exchange 2010

Third-party client application

When the move request has a status of Completion in Progress, the mailbox is locked for a short time. If users are using a third-party client application (such as Eudora), check with the manufacturer to determine whether users need to log off and then log on again after the move request is complete.

Exchange 2010

Outlook 2003 and Outlook Web Access

This is an offline move, and users can't access their mailbox during the move request process. However, users can use Outlook to access mail archived locally. User can't use Outlook Web Access during this time. When the move is complete, Outlook displays a message notifying users to close and restart Outlook. When the move request has a status of Completion in Progress, the mailbox is locked for a short time. Users experience an interruption only if the Outlook Web Access URL that they use has changed. If the URL has changed, users must modify the URL in their phone's e-mail settings. This is an offline move, and users can't access their mailbox during the move request process. However, users can use Outlook to access mail archived locally. Users can't use Outlook Web Access during this time. When the move is complete, Outlook displays a message notifying users to close and restart Outlook. This is an offline move, and users can't access their mailbox during the move request process. However, users can use Outlook to access mail archived locally. Users can't use Outlook Web Access during this time. When the move is complete, Outlook displays a message notifying users to close and restart Outlook.

Exchange 2010

Outlook Mobile Access

Exchange 2010

Exchange 2007 SP3

Outlook 2007 and Outlook Web Access

Exchange 2010

Exchange 2003 SP2

Outlook 2003 and Outlook Web Access

Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Offline Address Books

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-12-10 An offline address book (OAB) is a copy of a collection of address lists that has been downloaded so that a Microsoft Outlook user can access the information it contains while disconnected from the server. Microsoft Exchange generates the new OAB files, compresses the files, and then places the files on a local share. Exchange administrators can choose which address lists are made available to users who work offline, and they can also configure the method by which the address books are distributed. For more information about address lists, see Understanding Address Lists. Important: OAB data is produced by the Microsoft Exchange System Attendant service running as Local System. If an administrator uses the security descriptor to prevent users from viewing certain recipients in Active Directory, users who download the OAB will be able to view those hidden recipients. Therefore, to hide a recipient from an address list, you set the HiddenFromAddressListsEnabled parameter on the Set-PublicFolder, Set-MailContact, Set-MailUser, Set-DynamicDistributionGroup, SetMailbox, and Set-DistributionGroups cmdlets. Alternatively, you can create a new default OAB that doesn't contain the hidden recipients. For more information about how to add or remove address lists from an OAB, see Add or Remove an Address List from an Offline Address Book. Looking for management tasks related to managing Mailbox servers? See Managing Mailbox Servers. Contents Moving OABs Between Exchange Versions Outlook Clients and OAB Version OAB Distribution Methods OAB Considerations

Moving OABs Between Exchange Versions

Exchange supports moving OABs only in the following configurations:

Between servers running Microsoft Exchange Server 2010 From Exchange 2010 to Exchange Server 2007 servers From Exchange 2007 to Exchange 2010 servers From Exchange Server 2003 to Exchange 2010 servers Exchange doesn't support moving OABs from Exchange 2010 to Exchange 2003 servers. Return to top

Outlook Clients and OAB Version

You can specify the OAB versions that are generated for client download. The following options are available:

OAB version 2 (ANSI OAB) This OAB format is used with both Microsoft Exchange 2000 Server and Exchange Server version 5.5. Exchange 2003 also supports ANSI OABs. The following versions of Outlook supports OAB version 2: Outlook 2010 Office Outlook 2007 Office Outlook 2003 Outlook 2002 Outlook 2000 Outlook 98 OAB version 3 (Unicode OAB) This OAB is used for Exchange 2003. This OAB has additional information that helps Outlook reduce server remote procedure calls (RPCs). Additionally, the Unicode OAB has new features that are related to sorting rules for different language locales. These features permit the following versions of Outlook to use the correct sorting rule for the language locale with the OAB: Outlook 2010 Outlook 2007 Outlook 2003 OAB version 4 (Unicode OAB) This OAB was introduced in Exchange 2003 Service Pack 2 (SP2) and is supported by Outlook 2003 (SP2), Outlook 2007, and Outlook 2010. This Unicode OAB allows client computers to receive differential updates rather than full OAB downloads.

Outlook Clients That Use OAB Version 3 and Version 2

For Outlook clients that use OAB version 3 and version 2, if the size of the Changes.oab file is one-eighth (or more) the size of the entire OAB file, Outlook initiates a full OAB download. For example, Outlook will obtain the size of the compressed Changes.oab files. Outlook will then obtain the total size of all the compressed full OAB files on the

server, including the templates. If the size of the Changes.oab files is greater than one-eighth the size of the full OAB files, Outlook will download the full OAB instead of the incremental files. Minor changes to recipient attributes will cause all recipient information to be included in the Changes.oab file. The following are examples of these minor changes:

Updating phone numbers to reflect a new area code for a large number of recipients Adding an additional proxy address to a large number of recipients Therefore, changing minimal bytes of information for half of your recipients could create a Changes.oab file that's larger than one-eighth the size of your entire OAB file.

Outlook Clients That Use OAB Version 4

For Outlook 2010, Outlook 2007, and Outlook 2003 SP2 clients that use OAB version 4, if the size of the Changes.oab files is one-half (or more) the size of the entire OAB files, Outlook initiates a full OAB download. For more information about improvements that have been made in OAB version 4, see "Improvements in Exchange 2003 SP2 and Outlook 2003 SP2" in Improvements for Offline Address Books. Return to top

OAB Distribution Methods

You can choose which address books are made available to users who work offline. When the OAB generation (OABGen) process occurs, Exchange generates new OAB files, compresses the files, and then places the files on a local share. You can then configure the method by which the address books are distributed. There are two methods by which the OAB is distributed to client computers:

Web-based distribution Public folder distribution

Web-Based Distribution
Web-based distribution is the distribution method by which Outlook 2010 or Outlook 2007 clients that are working offline or through a dial-up connection access the OAB. If you use Web-based distribution, you don't have to use public folders. With Web-based distribution, after the OAB is generated, the Client Access server replicates the files. Web-based distribution uses HTTPS and Background Intelligent Transfer Service (BITS). For an overview about how BITS works, see About BITS. Important: Although Web-based distribution is enabled by default and doesn't require further configuration, we recommend that you enable Secure Sockets Layer (SSL) for the OAB distribution point. For more information, see Require SSL for Offline Address Book Distribution. There are several advantages to using Web-based distribution, including:

Support of more concurrent client computers. Reduction in bandwidth usage. More control over the OAB distribution points. With Web-based distribution, the distribution point is the HTTPS Web address where client computers can download the OAB. To benefit most from Web-based distribution, client computers must be running Outlook 2010 or Outlook 2007. Organizations that also have client computers running Outlook 2003 or earlier can use both public folder distribution and Web-based distribution. The Outlook 2003 Service Pack 1 (SP1) and earlier clients will still access their OABs by using public folders, while Outlook 2010 or Outlook 2007 clients will take advantage of the new Web-based distribution method. To function properly, Web-based distribution depends on the following components:

OAB generation process This is the process by which Exchange creates and updates the OAB. To create and update the OAB, the OABGen service runs on the OAB generation server. To support OAB distribution, this server must be an Exchange Mailbox server. Microsoft Exchange File Distribution service The Microsoft Exchange File Distribution service runs on Client Access servers and is responsible for gathering the OAB and keeping the content synched with the content on the Mailbox server. OAB virtual directory The OAB virtual directory is the distribution point used by the Web-based distribution method. By default, when Exchange is installed, a new virtual directory named OAB is created in the default internal Web site in Internet Information Services (IIS). If you have client-side users that connect to Outlook from outside your organization's firewall, you can add an external Web site. Alternatively, when you run the New-OABVirtualDirectory cmdlet in the Exchange Management Shell, a new virtual directory named OAB is created in the default IIS Web site on the local Exchange Client Access server. For information, see Create an Offline Address Book Virtual Directory. Autodiscover service This is a feature available in Outlook 2010 or Outlook 2007 and in some mobile devices that automatically configure the clients for access to Exchange. The service runs on a Client Access server and returns the correct OAB URL for a specific client connection. For more information about the Autodiscover service, see Understanding the Autodiscover Service. The following figure illustrates workflow for the OAB Web-based distribution method. The figure assumes that all client users have the same OAB and that the OAB is distributed to all Client Access servers.

In this figure, a company has offices in London and Sao Paulo. The Mailbox servers for the entire company are in the corporate headquarters in London. Sao Paulo, which is a slow link, has Client Access servers to which the Sao Paulo client users connect to Outlook. In addition, the company has users who work remotely and connect to the corporate network through the Internet. Before a user connects to a MAPI-based client computer, such as Outlook, the following happens:

1. The OAB is generated on one of the Mailbox servers in the London office. 2. On each of the Client Access servers in London, the Microsoft Exchange File Distribution service copies the new OAB files from the OAB Mailbox server in London. 3. On the Client Access server in Sao Paulo, the Microsoft Exchange File Distribution service copies the files over the slow link from the Mailbox server in London. Depending on the speed of the slow link, the copy process may take from several minutes to several hours. The new OAB isn't made available to client computers until it's completely copied and verified. Note: Not all Client Access servers will copy the new OAB at the exact same time. There is a poll interval (the default is 8 hours) that starts copying if there are new differential files. The first poll occurs when the Microsoft Exchange File Distribution service starts. Therefore, unless the Client Access servers were started at the same time, the server polls will be different on each Client Access server. After all of the Client Access servers have copied the OAB content, there are several scenarios by which the client user will download the OAB:

Scenario 1 Onsite user In this scenario, all actions occur in the London office: 1. User A, who's located in the London office and whose Outlook is set to Cached Exchange Mode, connects to Outlook. 2. Outlook connects to the Autodiscover service to obtain the URL to the closest OAB distribution point. 3. The Autodiscover service returns the URL to one of the Client Access servers in London. 4. Outlook uses BITS to connect to the URL that was provided by the Autodiscover service. 5. Outlook downloads the OAB. Scenario 2 Slow link user In this scenario, the User B mailbox resides in the London office because there are no Mailbox servers in the Sao Paulo office. Because User B is preparing to leave for a business trip and requires a local copy of the OAB, User B must download the OAB. The User B OAB will be downloaded from the Client Access server that's closest to the Sao Paulo office: 1. User B, who's located in the Sao Paulo office, connects to Outlook. 2. Outlook connects to the Autodiscover service to obtain the URL to the closest OAB distribution point. 3. The Autodiscover service returns the URL to the Client Access server in Sao Paulo. 4. Outlook uses BITS to connect to the URL that was provided by the Autodiscover service. 5. Outlook downloads the OAB. However, because the Sao Paulo Client Access server copies the OAB to London over a slow link, User B may not get the most recent version of the OAB. Scenario 3 Internet user In this scenario, because the user connects using the Internet, Exchange can't locate the Client Access server that's closest to the user's physical location. Therefore, Exchange defaults to a Client Access server that's close to the user's Mailbox server: 1. User C, whose Mailbox server is in London, connects to Outlook from the Internet. 2. Outlook connects to the Autodiscover service to obtain the URL to the closest OAB distribution point. 3. Because the User C mailbox is located on the Mailbox server in London, the Autodiscover service returns the URL to one of the Client Access servers in London. 4. Outlook connects to the URL that was provided by the Autodiscover service by using BITS. 5. Outlook downloads the OAB.

Public Folder Distribution

Public folder distribution is the distribution method by which Outlook 2003 SP1 or earlier clients that are working offline or through a dial-up connection access the OAB. With public folder distribution, the OAB generation process places the files directly in one of the public folders, and then Exchange store replication copies the data to other public folder distribution points. With public folder distribution, every request for a full OAB download is served immediately. For example, if a public folder that's serving 10,000 users receives 1,000 requests in one hour, and the OAB size is 5 megabytes (MB), the server will immediately transmit 5 gigabytes (GB) of data. Depending on network speed and available bandwidth, this volume of traffic could potentially overload the network for an extended period. To prevent this overload, you can set a bandwidth threshold to limit the network bandwidth that results from OAB downloads. This process is called throttling. By default, throttling is turned off. You can activate throttling by adding the following entry to the registry on all public folder servers that host OAB system folders.

Caution: Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem Type: DWORD Value: OAB Bandwidth Threshold (KBps)

Value Data: bandwidth threshold setting (Range: 0 to 4194304 (decimal)) The bandwidth threshold setting is in kilobytes per second (KBps) and should be configured with a decimal value. For example, setting the registry key to a decimal value of 5,000 configures the public folder server to use 5,000 KBps as the bandwidth threshold for OAB downloads, which is approximately 40,960 kilobits per second (Kbps), or 40.96 megabits per second (Mbps). After the setting has been added and configured, Exchange will dynamically detect the registry entry and begin enforcing the bandwidth limit without requiring the Microsoft Exchange Information Store service to restart. Each time an OAB download request occurs, administrative rights on the Exchange server are verified for the requestor. If the security context that's used for the request is the equivalent of the local administrator on the Exchange server, it's assumed that an internal function is requesting the download. In this event, the requestor is allowed to proceed with a full OAB download. However, the bytes that are transmitted to the administrative client are still calculated as part of the average full OAB bytes downloaded. If the requestor doesn't have administrative rights, the average full OAB bytes that are downloaded over the last 10 seconds are determined. If this value is less than the configured threshold, a full OAB download is allowed. Note: Setting the registry key to 0 allows a maximum of one client without administrative rights, in 10 second intervals, at a time to download a full OAB. When setting the OAB download bandwidth threshold, we recommend that you configure thresholds on the individual servers to values that won't cause an overload of the Exchange server's network adapter or the network. If you haven't already gathered and analyzed network and Exchange server performance data, you should do so before you configure the registry entry.

Effects of OAB Downloads on the Network When Using Public Folder Distribution
Because there are several cases that can cause a large number of full OAB downloads, you should understand the effect on bandwidth that a large OAB download has on the network. The Exchange server can easily handle many download requests for the OAB. As a result, multiple attempts to download a full OAB over a slow link can saturate a network. (All the available bandwidth is being used.) When this happens, there are two significant effects:

Applications that must use the wide area network (WAN) will perform slowly. This is because they wait for their network requests to traverse the saturated WAN link. The actual traffic needed on the WAN increases because individual network requests may time out, resulting in additional requests being made. When the network becomes saturated, the latency increases, not only the time it takes for each client computer to download the OAB, but the overall duration of the download process. Normally, this means that the data rate for each client computer is reduced. However, if the latency is too high, RPC packets will time out, causing additional RPC requests for the same data to be retrieved. Also, if an Outlook user attempts to download the OAB and the download is canceled or fails, Outlook deletes the data that has been downloaded and attempts to download the OAB again. As a result, more data is requested, which in turn, increases the overall duration for a large set of OAB downloads. Outlook downloads the OAB from the Exchange server through a series of RPC packets. Each packet is received and acknowledged, and then the next packet is sent. Based on the latency between Outlook and Exchange, a single Outlook client is limited to how quickly it can receive and acknowledge each packet. Because of this delay, a single Outlook client may not be able to saturate a network link. However, as more Outlook clients begin to download the OAB, the combined download rate of all clients could saturate the link. The link will remain saturated until the full OABs are downloaded. The relationship is linear in that the larger the latency between the Outlook client and the Exchange server, the fewer packets can be received. Fewer clients are able to download an OAB before a slow link is saturated. The reverse is also true. If latency is low, more clients are needed to saturate a slow link. The number of Outlook clients that can download the OAB simultaneously without saturating the WAN will increase as either network latency decreases or network bandwidth increases. Return to top

OAB Considerations
As a best practice, whether you use a single OAB or multiple OABs, consider the following factors as you plan and implement your OAB strategy:

Size of each OAB in your organization. For more information, see "OAB Size Considerations" later in this topic. Number of OAB downloads. Number and frequency of parent distinguished name changes. SMTP address mismatches. Overall number of changes made to the directory.

OAB Size Considerations

For some organizations, the OAB is a small file that remote users occasionally download. For these organizations, downloading the OAB is usually not a concern. However, for some large organizations that have large directories, or for organizations that have deployed Outlook 2003 in Cached Exchange Mode, it may be a concern, especially if the organizations have consolidated Exchange servers into a regional data center. OAB sizes can vary from a few megabytes to a few hundred megabytes. The following factors can affect the size of the OAB:

Usage of certificates in a company. The more public key infrastructure (PKI) certificates, the larger the OAB. PKI certificates range from 1 kilobyte (KB) to 3 KB. They're the single largest contributor to the OAB size. Number of mail recipients in Active Directory. Number of distribution groups in Active Directory. Information that a company adds to Active Directory for each mailbox-enabled or mail-enabled object. For example, some organizations populate the address properties on each user; others don't. Return to top

 2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Public Folders

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-11-17 Public folders, introduced in the first version of Microsoft Exchange, are designed for shared access and provide an easy and effective way to collect, organize, and share information with other people in your workgroup or organization. Public folders are hierarchically organized, stored in dedicated databases, and can be replicated between servers running Exchange. Public folders aren't designed for the following purposes:

Archiving data Public folders aren't designed for archiving data. Users who have mailbox limits sometimes use public folders instead of their personal folders (.pst) files to archive data. This practice isn't recommended because it affects storage on public folder servers and undermines the goal of mailbox limits. Document sharing and collaboration Public folders aren't designed for document sharing and collaboration. Public folders don't provide versioning or other document management features, such as controlled check-in and check-out functionality, and automatic notifications of content changes. In Exchange Server 2010, public folders are an optional feature. If all client computers in your organization are running Microsoft Outlook 2010 or Office Outlook 2007, there are no dependencies on public folders for features such as free and busy information and offline address book (OAB) downloads. Instead of using public folders for OAB downloads and free and busy information, in Exchange 2010, these features are serviced by the Autodiscover service, the Microsoft Exchange System Attendant service, and the Microsoft Exchange File Distribution service. Until all client computers in your organization are running Outlook 2010 or Outlook 2007, you should continue using public folders. Contents

Public Folder Database Creation During Setup Public Folder Trees Public Folder Replication Public Folder Referrals Mail-Enabled Public Folders Public Folder Access Considerations with Mixed Exchange 2010 and Exchange 2007 Organizations Considerations with Mixed Exchange 2010 and Exchange 2003 Organizations Updating the Public Folder Hierarchy Public Folder Content Replication Best Practices

Public Folder Database Creation During Setup

Computers running Outlook 2003 and earlier or Microsoft Entourage require a public folder database (previously called the public folder store) to connect to Exchange. Therefore, in a pure Exchange 2010 organization, as you install the Mailbox server role on the first server, Setup prompts you with the question: Do you have any client computers running Outlook 2003 and earlier or Entourage in your organization? If the answer is yes, a public folder database is created. If the answer is no, a public folder database isn't created. When you install the second server, you aren't prompted with the question, and Setup doesn't create a public folder database. Whether a public folder database is needed in the organization is decided only when you install the first server. After that, all public folder databases are optional. If you don't create a public folder database during Setup, you can always create one anytime after Setup is complete. For more information about how to create a public folder database, see Create a Public Folder Database. In a mixed Exchange organization, Setup doesn't prompt you with the question. In these organizations, to ensure backward compatibility to Exchange versions prior to Exchange Server 2007, a public folder database is created by default. Specifically, because Exchange 2010 is installed in its own administrative group, this public folder database will support legacy Schedule+ free and busy functionality. For more information about installing Exchange 2010, see Deploying Exchange 2010. Return to top

Public Folder Trees

The MAPI folder tree is divided into the following subtrees:

Default public folders (also known as the IPM_Subtree) Users can access these folders directly by using client applications such as Outlook. System public folders (also known as the Non_IPM_Subtree) Users can't access these folders directly by using conventional methods. Client applications such as Outlook use these folders to store information such as free and busy data, OABs, and organizational forms. Other system folders contain configuration information used by custom applications or by Exchange. The public folder tree contains additional system folders, such as the EFORMS REGISTRY folder, that don't exist in general purpose public folder trees. System folders include the following: EFORMS REGISTRY and Events Root By default, one content replica of each of these folders resides in the default public folder database on the first Exchange server installed in the first administrative group. This is the location where organizational forms are stored for legacy Outlook clients (clients using an Outlook version earlier than Outlook 2007). Offline Address Book and Schedule+ Free Busy The Offline Address Book folder and the Schedule+ Free Busy folder automatically contain a subfolder for each administrative group (or site) in your topology. By default, a content replica of a specific administrative group folder resides on the first server installed in the administrative group. These folders are used to store legacy free and busy information and OAB data for legacy Outlook clients. Legacy Outlook clients don't support the new features in Exchange 2010 or Exchange 2007 that manage free and busy information and OAB data. (These features include the Availability service, the Autodiscover service, and OAB distribution on Client Access servers.) OWAScratchPad Each public folder database has an OWAScratchPad folder, which is used to temporarily store attachments that are being accessed by using Microsoft Office Outlook Web App. Don't modify this folder.

StoreEvents Each public folder database has a StoreEvents folder, which holds registration information for custom Exchange database events. Don't modify this folder. Other folders To support internal Exchange database operations, a tree may contain several other system folders, such as schema-root. Don't modify these folders. Return to top

Public Folder Replication

Public folder databases replicate two types of public folder information:

Hierarchy Properties of the folders and organizational information about the folders (including the tree structure). All public folder databases have a copy of the hierarchy information. For a specific folder, the public folder database can use hierarchy information to identify the following: Permissions on the folder Servers that hold content replicas of the folder Folder's position in the public folder tree (including its parent and child folders, if any) Content Messages that form the content of the folders. To replicate content, you must configure a folder to replicate its content to a specific public folder database or list of databases. Only the databases that you specify will have copies of the content. A copy of the folder that includes content is called a content replica. Note: Public folder content replication isn't controlled by database availability groups (DAGs). You can have public folder databases on servers that have DAGs; however, the public folders will use their own public folder replication methods outside of the DAG. To learn more about public folder replication, see Understanding Public Folder Replication. Return to top

Public Folder Referrals

When a client application, such as Outlook, attempts to open an Exchange public folder, the Exchange server determines which folder replica the client application should access. This process is called public folder referral. If a replica of the requested content exists on the Exchange server that serves the request, the client application accesses the local replica. If the replica doesn't exist on the local server, Exchange attempts to locate a replica in the same Active Directory site. You can modify the flow of user traffic to allow referrals over certain connectors by specifying a list of referral servers and assigning a routing cost to each server. For more information about public folder referrals, see Understanding Public Folder Referrals. Return to top

Mail-Enabled Public Folders

Mail-enabling a public folder provides an extra level of functionality to users. In addition to being able to post messages to the folder, users can send e-mail messages to, and sometimes receive e-mail messages from, the folder. If you're developing custom applications, you can use this feature to move messages or documents into or out of public folders. A mail-enabled folder is a public folder that has an e-mail address. Depending on how the folder is configured, it may appear in the global address list (GAL). Each mailenabled folder has an object in Active Directory that stores its e-mail address, address list name, and other mail-related attributes. Because mail sent to public folders is directed to the public folder database instead of to a mailbox in the mailbox database, Exchange routes e-mail messages by using a method that's slightly different from the method used to route e-mail messages to a regular mailbox. Return to top

Public Folder Access

In Exchange 2010, the following client applications can access public folders:

Outlook 2010 Outlook 2007 Outlook 2003 For more information about how to create and manage public folders by using Outlook 2007, see Create and share a public folder. For more information about how to create and manage public folders by using Outlook 2003, see Using Public Folders. Return to top

Considerations with Mixed Exchange 2010 and Exchange 2007 Organizations

In a mixed Exchange 2010 and Exchange 2007 organization, you need to manage your public folders and public folder databases from Exchange 2010. Exchange 2007 servers don't recognize Exchange 2010 public folder databases due to Active Directory schema changes. The following table describes the expected behaviors when performing certain public folder management tasks on Exchange 2007 servers and Exchange 2010 servers.

Tasks Create a public folder database

Exchange 2007 servers If any Exchange 2010 mailbox databases are in your organization and don't have the msExchHomePublicDB attribute populated, the Exchange 2007 server can't update the Exchange 2010 mailbox database's msExchHomePublicDB setting. Although you receive an error message, the public folder database is created. After you create the public folder database, you need to change the default public folder database. You need to perform this procedure from an Exchange 2010 server. For details, see Change the Default Public Folder Database for a Mailbox Database. If any mailbox databases are pointing to the public folder database that you're trying to remove, you receive an error message advising that you need to change the default public folder database. To change the default public folder database, perform the following steps: 1. On an Exchange 2010 server, change the default public folder database for the mailbox database. For details, see Change the Default Public Folder Database for a Mailbox Database. 2. On the Exchange 2007 server, remove all replicas of that public folder database. For details, see Remove Multiple Public Folders from a Public Folder Database. 3. On the Exchange 2007 server, remove the public folder database. For details, see Remove Public Folder Databases. Note: If the new default public folder database that you're pointing the mailbox databases to is an Exchange 2010 public folder database, see "Set an Exchange 2010 public folder database as the default public folder database for an Exchange 2007 mailbox database" later in this table.

Exchange 2010 servers Always works.

Remove the default public folder database

Works on both Exchange 2007 and Exchange 2010 servers provided that no mailbox databases have the public folder database that you're trying to remove as the default public folder database.

Remove the last public folder database in the organization

If this is the last Exchange 2007 public folder database in the organization, the Remove-PublicFolderDatabase cmdlet needs to update the msExchFirstInstance property on the Exchange 2010 public folder database to $true. This fails because the object version of the Exchange 2010 object is higher. Run the Remove-PublicFolderDatabase cmdlet from the Exchange 2010 server.

Works on both Exchange 2007 and Exchange 2010 servers provided that no mailbox databases have the public folder database that you're trying to remove as the default public folder database.

Set an Exchange 2010 public folder database as the default public folder database for an Exchange 2007 mailbox database

Changing the default public folder database doesn't work on an Exchange 2007 server if either the mailbox database or the public folder database is an Exchange 2010 database. Because Exchange 2007 servers don't recognize the Exchange 2010 public folder databases, the Set-MailboxDatabase cmdlet must be run on an Exchange 2010 server. On the Exchange 2010 server, change the default public folder database for the Exchange 2007 mailbox database. For details, see Change the Default Public Folder Database for a Mailbox Database.

Always works and should be used to change the default public folder databases if your public folder database and your mailbox database are associated with different versions of Exchange.

Return to top

Considerations with Mixed Exchange 2010 and Exchange 2003 Organizations

When you install Exchange 2010 in an Exchange 2003 organization, Setup automatically creates an administrative group and routing group within the Exchange 2003 organization. The Exchange 2010 servers added to your organization are included in the new administrative group and routing group. As previously mentioned, Setup also installs a public folder database on the first Exchange 2010 Mailbox server. In that public folder database, Setup creates a free and busy folder for the new administrative group. The legacyExchangeDN property for users whose mailboxes were created on an Exchange 2010 server (and not migrated from Exchange 2003) maps to the Exchange 2010 administrative group name, and therefore also maps to the Free/Busy folder. By default, to facilitate free and busy searches from Outlook 2003 and earlier client users whose mailboxes reside on an Exchange 2003 server, the client users' free and busy information is posted to the Free/Busy public folder.

Management
In a mixed Exchange 2010, Exchange 2007, and Exchange 2003 organization, you can use Exchange System Manager to manage public folders. The following scenarios are supported:

Exchange System Manager should only connect to the Exchange 2003 public folder database for administration. From there, changes replicate to Exchange 2010. In a pure Exchange 2010 environment or a mixed Exchange 2010 and Exchange 2007 organization, you can't reinstall Exchange System Manager to manage public folders. You must use the Exchange Management Shell. When verifying hierarchy replication or when viewing the Local Replica Age Limit value on a folder, we recommend using Exchange System Manager for public folders that exist on an Exchange 2003 server and using the Shell for public folders that exist on an Exchange 2010 or Exchange 2007 server.

Outlook Web App

In a mixed Exchange 2010, Exchange 2007, and Exchange 2003 organization, one of the Exchange 2010 and Exchange 2007 Client Access servers has a virtual directory named /public. You can fully access public folders from Outlook Web App without having to use the /public virtual directory.

Important: Exchange 2010 Outlook Web App clients cant view public folders that reside on Exchange 2003 servers. In addition, the following public folder features are available in Outlook Web App:

Full access to public folders on Exchange 2010 Mailbox servers without having to keep an Exchange 2003 Mailbox server available for public folder access from Outlook Web App Public folder search capabilities Web Parts support Return to top

Updating the Public Folder Hierarchy

If you notice that the public folder hierarchy on one server is different from the public folder hierarchy on other servers, you may want to synchronize the hierarchy. In Exchange 2003 Service Pack 2 (SP2), the Synchronize Hierarchy command is used to synchronize the public folder hierarchy on an Exchange 2003 server with the other servers in your organization. In Exchange 2010, the Update-PublicFolderHierarchy cmdlet is used to synchronize the public folder hierarchy on the Exchange 2010 server with the rest of the servers in your organization. Note: You can't run the Synchronize Hierarchy command on an Exchange 2010 server. Similarly, you can't run the Update-PublicFolderHierarchy cmdlet on an Exchange 2003 server. However, running either command updates the public folder hierarchy in your entire organization. For more information, see Update a Public Folder Hierarchy. Return to top

Public Folder Content Replication

To help stop public folder content replication errors in your organization, you can suspend the replication of public folder content. Suspending replication allows you to reconfigure the public folder hierarchy and replication schedules. To suspend or resume the replication of public folder content in a mixed organization, on an Exchange 2010 server, run the Suspend-PublicFolderReplication cmdlet or the Resume-PublicFolderReplication cmdlet in the Shell. Although you run these cmdlets on an Exchange 2010 server, they will suspend or resume the replication of public folder content on all servers in your mixed organization. For information about using the Shell to suspend or resume the replication of public folder content, see the following topics:

Suspend Public Folder Content Replication Resume Public Folder Content Replication Return to top

Best Practices
This section provides the best practices to consider when performing the following public folder tasks in your Exchange organization:

Creating public folder databases Designing the public folder hierarchy Performing nightly maintenance

Creating Public Folder Databases

When you plan how many public folder databases to create in your organization, consider the following best practices:

For large enterprise topologies where public folders are heavily used, deploy dedicated public folder servers. This best practice stems from the general best practice of dedicating CPU resources and disk resources to isolated server functions. Having fewer larger public folder databases scales better and is more easily managed than having several smaller public folder databases. By reducing the number of public folder databases, you can decrease the time required to back up and restore many smaller databases. You also reduce the amount of background replication traffic. Additionally, online maintenance of fewer larger databases is quicker than online maintenance of many smaller databases. Also, it is easier to manage a smaller number of public folder databases from the perspective of applying permissions and content access, and implementing efficient replication and referrals. The best practice of having fewer larger public folder databases is especially helpful when you consider your topology from the organization level. However, at the server level, some management and maintenance tasks, such as backup and restore processes, can be more quickly performed if you have several smaller databases. Ultimately, the number of public folder databases that you deploy must address your business requirements. As you determine the number of databases that you want to deploy, you must balance the cost of replication traffic against the costs of database backup, maintenance, and restore times.

Designing the Public Folder Hierarchy

As you design your public folder hierarchy, you must recognize the effect of hierarchy replication in your environment. Deep public folder hierarchies scale better than wide hierarchies. A deep hierarchy consists of many vertically nested folders, instead of many higher-level folders. A wide hierarchy consists of many higher-level folders with fewer vertically nested subfolders.

For example, consider how 250 folders might be arranged in a specific hierarchy. A wide hierarchy might have 250 direct subfolders under one parent folder. A deep hierarchy might have five top-level folders, each with five direct subfolders. Inside each of those subfolders may be 10 subfolders. In both these examples, there are 250 folders 5 5 10 = 250. However, the deep hierarchy offers better performance than the wide hierarchy for the following reasons:

The way that replication handles folders that have different permissions applied to them is more efficient in deep hierarchies. Client computer actions (such as sort, search, and expand) against a folder that has 10 subfolders is much less expensive than a folder that has 250 subfolders. Although deep hierarchies scale better than wide hierarchies, it's a best practice not to exceed 250 subfolders per folder. Exceeding 250 subfolders likely will cause an unacceptable client experience when a client computer requests access. A factor to consider as you implement a hierarchy is the effect that permissions have on the experience users have when they want to gain access to public folders. When each public folder subfolder has its own access control list (ACL) entries defined, every time that the Exchange server receives a new public folder replication message, the ACL for the parent public folder must be evaluated to determine which users have rights to view the changes to the parent public folder. If the parent public folder has a large discretionary access control list (DACL) entry, it may take a long time to update the view for each public folder subscriber. Note: The DACL for the parent folder consists of the sum of the DACLs of all the public folder subfolders. You may have many megabytes (MB) of DACL data that must be parsed if the following conditions are true:

There are many subfolders under a single parent public folder. Each of those subfolders has its own ACL defined. This DACL data must be parsed so that the display can be updated for all the public folder subscribers every time that a public folder replication message is received. Therefore, we recommend that you arrange your public folder hierarchy according to the user sets that gain access to the parent folders. Additionally, don't implement complex permission models for your public folder hierarchies.

Performing Nightly Maintenance

To make sure that your databases continue to operate efficiently, we recommend that you perform nightly maintenance on mailbox databases and public folder databases. Exchange Mailbox servers automate the tasks based upon the schedule that you set. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Public Folder Permissions

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-01-13 You can configure public folder permissions for administrators or for users of client programs such as Microsoft Outlook. Public folder permissions consist of various access rights that specify the level of control a client user or administrator has over a public folder or public folder hierarchy. Looking for management tasks related to public folder permissions? Check out Managing Public Folder Permissions.

Client User Access Rights and Roles

Use the Exchange Management Shell to configure the permissions for users who use client programs such as Outlook to access public folders. Whether you want to manually select the access rights or use predefined roles that contain specific access rights, you'll use the Add-PublicFolderClientPermission cmdlet. Important: To make sure users can send e-mail messages to a mail-enabled public folder, the public folder must have at least the CreateItems access right granted to the Anonymous account. The following is a list of client user access rights (followed by a table that shows the predefined permission roles):

ReadItems The user can read items within the specified public folder. CreateItems The user can create items within the specified public folder and send e-mail messages to the public folder if it's mail-enabled. EditOwnedItems The user can edit the items that the user owns in the specified public folder. DeleteOwnedItems The user can delete items that the user owns in the specified public folder. EditAllItems The user can edit all items in the specified public folder. DeleteAllItems The user can delete all items in the specified public folder. CreateSubfolders The user can create subfolders in the specified public folder. FolderOwner The user is the owner of the specified public folder. The user can view and move the public folder, create subfolders, and set permissions for the folder. The user can't read, edit, delete, or create items. FolderContact The user is the contact for the specified public folder. FolderVisible The user can view the specified public folder, but can't read or edit items within the specified public folder. The following table lists the predefined public folder roles and the access rights that are included in each role. The table headers reflect the access rights listed previously in this topic. Note: The FolderOwner access right and the Owner role have different permissions as shown in the following table.

Access rights included with each predefined public folder role

Role CreateItems ReadItems CreateSubfolders FolderOwner Folder Contact FolderVisible EditOwnedItems EditAllItems DeleteOwnedItems

None Owner PublishingEditor Editor PublishingAuthor Author NonEditingAuthor Reviewer Contributor Note: X X X X X X X X X X X X X X X X X X

X X X X X X X X X X X X X X X X X X X X

X X

Client users can use Outlook to manage public folder permissions for public folders that reside on a server running Microsoft Exchange Server 2010. For information about how to manage public folder permissions from Microsoft Office Outlook 2007 or Outlook 2010, see Create and Share a Public Folder. For information about how to manage public folder permissions for public folders that reside on Exchange 2010 servers from Office Outlook 2003, see Outlook folder permissions.

Administrator Access Rights

In Exchange 2010, there are two ways to grant administrators the rights to manage public folders:

Public Folder Management role group Add-PublicFolderAdministrativePermission cmdlet The following table describes the differences between the rights that are granted by the Public Folder Management role group and the rights that are granted by using the Add-PublicFolderAdministrativePermission cmdlet.

Administrator access rights differences

Public Folder Management role group The user can create top-level public folders. The user is granted the AllExtendedRights permission to public folders and the rights to run the public folder cmdlets. The user can administer any top-level public folder, child public folder, and system public folders in the public folder tree. In addition, this user's access rights can't be revoked by using the Remove-PublicFolderAdministrativePermission cmdlet. The Public Folder Management role group is a Role Based Access Control (RBAC) role group that consists of the following roles: Mail-Enabled Public Folders role Public Folders role Public Folder Replication role For more information, see Public Folder Management. The following list describes the standard set of administrative access rights that can be set on a public folder: Add-PublicFolderAdministrativePermission cmdlet The user can't create top-level public folders. The user can be granted or denied specific rights to public folders.

The user can be granted the right to administer specific top-level public folders and specific child public folders. However, the user's access rights can be revoked by using the Remove-PublicFolderAdministrativePermission cmdlet. Not applicable

None The administrator doesn't have any rights to modify public folder attributes. ModifyPublicFolderACL The administrator has the right to modify Client Access server role permissions for the specified folder. ModifyPublicFolderAdminACL The administrator has the right to modify administrator permissions for the specified public folder. ModifyPublicFolderDeletedItemRetention The administrator has the right to modify the Public Folder Deleted Item Retention attributes (RetainDeletedItemsFor, UseDatabaseRetentionDefaults). ModifyPublicFolderExpiry The administrator has the right to modify the Public Folder Expiration attributes (AgeLimit, UseDatabaseAgeDefaults). ModifyPublicFolderQuotas The administrator has the right to modify the Public Folder Quota attributes (MaxItemSize, PostQuota, PostWarningQuota, UseDatabaseQuotaDefaults) ModifyPublicFolderReplicaList The administrator has the right to modify the replica list attribute for the specified public folder (Replicas). AdministerInformationStore The administrator has the right to modify all other public folder properties not defined previously. ViewInformationStore The administrator has the right to view public folder properties. AllExtendedRights The administrator has the right to modify all public folder properties.

Creating Custom Role Groups

In addition to the Public Folder Management role group and the Add-PublicFolderAdministrativePermission cmdlet, you can create custom role groups that will allow a user to only perform certain tasks. For example, if you want to allow an administrator to manage public folders and mail-enabled public folders, but not public folder replication, you can create a custom role group that includes only the Mail Enabled Public Folders role and the Public Folders role. For more information about creating role groups, see Create a Role Group.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Public Folder Replication

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-12-07 Public folder replication is the process by which public folder content and the public folder hierarchy are replicated across multiple servers for efficiency and fault tolerance purposes. When multiple public folder databases located on separate servers support a single public folder tree, Microsoft Exchange uses public folder replication to keep the databases synchronized. Public folder content exists only in Exchange stores configured to have a replica of a specific folder. Content and hierarchy information are replicated separately. Each public folder database retains a copy of the hierarchy, which includes lists of the other public folder databases that retain content replicas of each folder. Content replicas exist only on the public folder databases that you specify. For more information about how to configure public folder replication, see Configure Public Folder Replication. Note: Unlike in Exchange Server 2007, you can't use continuous replication in Exchange Server 2010 to replicate public folders. In Exchange 2010, continuous replication is for mailbox databases only. A public folder database can be hosted on a Mailbox server in a database availability group (DAG), but you must use multiple public folder databases and public folder replication for data redundancy. Public folder databases replicate two types of public folder information:

Hierarchy Hierarchy replication occurs when the properties of the folders and organizational information about the folders have been modified. All public folder databases have a copy of the hierarchy information. Modifying the following public folder information results in hierarchy replication: Folder name Replica list Folder's position in the public folder tree (including any parent and child folders) Permissions Note: Hierarchy replication doesn't occur when you change the e-mail addresses for a mail-enabled public folder. The e-mail addresses are stored on the directory object in Active Directory. Only by changing the properties within the public store database does hierarchy replication occur. Content Content replication occurs when messages are sent to public folders or when data is added. For example, sending e-mail messages to a mail-enabled public folder or adding an organizational form to a public folder results in content replication. To replicate content, you must configure a folder to replicate its content to a specific public folder database or list of databases. Only the databases that you specify will have copies of the content. A copy of the folder that includes content is called a content replica. Contents How Public Folder Replication Works Replication Messages Backfill Requests and Backfill Messages Examples of Replication Cycles Best Practices for Implementing Replication Looking for management tasks related to public folders? See Managing Public Folders.

How Public Folder Replication Works

When you modify a public folder or its contents, the public folder database that contains the replica of the public folder that was changed sends a descriptive e-mail message to the other public folder databases that host a replica of the public folder. To reduce traffic on your network, Exchange includes information about multiple changes in one e-mail message. The amount of information included in these messages depends on the size limit you set for replication messages. If any message exceeds the specified size limit, that message is sent as a separate replication message. Exchange routes these replication messages the same way that it routes other e-mail messages. If you make changes to the public folder hierarchy that affect several folders, the replication process may require considerable network bandwidth. For example, to move public folders from one server to another, you must create replicas on the server to which you want to move the public folders, wait for the hierarchy changes to replicate to the original server, and then wait for the content to replicate to the new replicas. After the replicas are synchronized, you must remove the replicas from the old server. Even removing the replicas from the old server generates network traffic because removing replicas must replicate as a hierarchy change. To learn more about how these changes to the public folder hierarchy can affect your system, see "Status Requests and Status Messages" later in this topic.

Basic Hierarchy and Content Replication Process

The following figure and the explanatory text that follows describe the basic process by which public folder hierarchy and public folder content are replicated.

The details of the process are as follows:

1. A user modifies the public folder. 2. The local public folder database records the change. 3. At the next scheduled replication cycle (which is determined by the replication interval that you set for the public folder database), the public folder database checks the folder properties to determine which other servers contain a replica of that folder. If other replicas exist, the database determines what information must be replicated to them. This information becomes the update to the replicas. Public folder replication is object-based. If one property of an object is modified, the entire object must be replicated. Because the database that replicates the change can't assume that all of the receiving replicas are up to date, it must replicate the entire object. The implications for the different types of replication are as follows: Hierarchy replication The replication of new hierarchy changes occurs when a public folder is created or deleted, or when a change is made to the properties of a public folder (such as a change to the replica list, client permissions, description, administrative note, or storage limits). Content replication If a new message is posted or an existing message is modified, the update includes the entire message and its properties. 4. The public folder database assigns a change number to the update. When a folder replicates an update to another server, the change number is included with the update. The receiving server then uses the change number to determine whether the update represents a new change, and whether the server is missing any data. 5. The public folder database packs updates into a replication message. The change numbers of all of the updates in the message are called a change number set (CNSet). Along with the updates, the public folder database packs information from the folder's entries that are in the replication state table, including the CNSets that were previously applied to the replica. For more information about the replication state table, see "Replication State Table" later in this topic. 6. To reduce mail traffic, the public folder database packs multiple hierarchy updates into a single replication message. Likewise, the database packs multiple content updates for the same folder into a single replication message. However, the database can't pack hierarchy updates into the same replication message as content updates, and each content replication message contains updates for a single folder. 7. The public folder database addresses the replication message to the other public folder databases that host replicas of the updated folder. The database sends the message, along with any other messages that have been packed since the previous replication cycle. To deliver replication messages, the public folder database relies on the internal routing components in Exchange. The database doesn't attempt to split replication messages based on topology details. If the contents of a folder are modified and the folder has five other replicas, the database generates a single replication message and addresses it to all five databases that host those replicas. The routing components determine how to route and deliver the message. 8. The public folder database receives the replication message. 9. The receiving public folder database unpacks the update and status information from the replication message. 10. The database compares the change numbers of the new updates to the list of change numbers that it already contains, and then identifies which updates it hasn't previously received. 11. The database applies the new updates to the appropriate folder replicas. 12. For each updated replica, the database updates the replication state table with the change numbers of the current update and the folder status information from the replication message. If the information in the replication state table indicates that other CNSets have been applied to other replicas of the folder but not to replicas on this database, the database records the CNSets that are missing in a location called the backfill array, and then prepares to send a backfill request. For more information about backfill requests, see "Backfill Requests and Backfill Messages" later in this topic. Return to top

Replication Messages
The replication process uses the Active Directory attributes of the public folder databases, and not the Active Directory attributes of individual public folders. The Active Directory attributes for individual public folders are used only to send regular e-mail messages to or from the folders. A public folder database object is configured and maintained automatically and resides in the Configuration container in Active Directory. Replication messages differ from other e-mail messages in that Exchange treats replication messages as system messages. This means that replication messages aren't bound by the restrictions applied to user e-mail messages (such as size and delivery restrictions). The following table lists the different types of replication messages that Exchange uses. Note:

The values listed in parentheses in the following table are the hexadecimal notation of the message types. These notations are used in events and logs. You can use the hexadecimal value to troubleshoot replication issues.

Types of public folder replication messages and when they are used
Message type* Hierarchy (0x2) When used Replicates hierarchy changes from the local public folder database to all other public folder databases that support the same hierarchy. Although Exchange handles hierarchy changes separately from changes to content replicas, it treats the hierarchy as if it was another folder. In some event messages and other operations, Exchange refers to the hierarchy as Folder 1-1. Replicates content changes from one replica to all other content replicas of that folder. A content message only contains information that applies to a single folder. Requests missing data in CNSets from another database. This includes hierarchy and content change numbers.

Content (0x4)

Backfill request (0x8) Backfill response (0x80000002 or 0x80000004) Status (0x10) Status request (0x20)

Sends missing data in CNSets to a database that requested missed updates.

Sends the current CNSet of a folder to one or more replicas of that folder. This includes hierarchy and content change numbers. Requests CNSets to be replicated or status messages to be returned. This includes hierarchy and content change numbers.

Replication State Table

Each public folder database maintains a replication state table to track the status of each replica in the database. The replication state table stores the following information:

Basic information required to construct updates to each replica. Information about the last update to each replica that originated in the local database, including the change number of the update. Groups of updates that have been applied to all other known replicas of the folder. Change numbers identify the updates in each group. The set of change numbers for all updates in a group is called a CNSet. Update information is passed from one database to another as part of the replication process. The following tables provide an example of how replication state tables function. In this example, the public folder databases on Server A and Server B both have replicas of a folder named Projects. On each server, the replication state table tracks not only the status of the replica on that server, but also the status of the replica on the other server. Using this information, Server A determines whether its replica of Projects folder is synchronized with the replica of the Projects folder on Server B. Server B can likewise track its status relative to Server A.

Sample data from the replication state table for Server A

Replica Projects folder on Server A (local replica) Projects folder on Server B Data Last update sent: A-100

A-100 received B-50 received

Sample data from the replication state table for Server B

Replica Projects folder on Server A Data A-100 received B-50 received Last update sent: B-50

Projects folder on Server B (local replica)

By combining the lists of public folder databases that contain content replicas with the information in the replication state table, each public folder database can determine how up to date it is compared to the other public folder databases that support the public folder tree. Return to top

Backfill Requests and Backfill Messages

Backfilling occurs when a public folder database determines that it hasn't received all the updates for a replicated folder (or for the hierarchy) and must therefore retrieve the missing updates from another public folder database. To streamline the backfill process, Exchange stores information about missing updates in the backfill array. The following events may alert a public folder database to missing updates that need to be backfilled:

The status information in an incoming replication message indicates that the replica on the public folder database that sent the message has updates that are

missing on the receiving database. The receiving database identifies the missing change numbers and stores them in its backfill array. A public folder database starts for the first time. The new database sends status requests to get information about the other databases in the hierarchy. After the corresponding status messages arrive, the database populates its replication state table and, if necessary, the backfill array. The backfill array may contain entries for both the hierarchy and for any content replicas that the database must host. An incoming hierarchy message indicates that a new content replica is to be placed in the public folder database. The new database sends status requests to get information about content that might be available for this replica in the other databases in the hierarchy. After the corresponding status messages arrive, the database populates the replication state table and, if necessary, the backfill array. The backfill array stores this information for a specified length of time (called the backfill time-out). If the missing updates arrive in subsequent replication messages during this time, they are removed from the backfill array. The following table lists the default backfill time-out values, which depend on where the missing updates exist and whether they were previously requested.

Default time-outs used for backfill requests

Type of request Initial backfill First backfill retry Subsequent backfill retries Content exists on a database in the local Active Directory site 6 hours 12 hours 24 hours Content exists on a database in a remote Active Directory site 12 hours 24 hours 48 hours

If the backfill time-out expires, and the updates are still missing, Exchange creates one or more backfill requests and determines which servers to use as backfill sources. To select servers to use as a backfill source, Exchange first creates a list of all the servers that have replicas of the folder, and then sorts the list according to the following sequence of criteria:

1. Sort according to server status. Servers that are down or unavailable drop to the end of the list. 2. Sort according to preferred backfill server (if any). Exchange checks the public folder database object in Active Directory for a preferred backfill server. This setting is seldom used. In most circumstances, the backfill process operates most efficiently if Exchange selects a backfill server automatically. Most deployments of Exchange don't need a preferred backfill server. Microsoft Customer Service and Support can provide a script that sets a preferred backfill server if your deployment requires it. 3. Sort according to transport cost (lowest to highest). Servers in the same routing group have priority over servers in remote Active Directory sites. 4. Sort according to Exchange version (newest to oldest). 5. Sort according to the number of necessary changes available on the server (largest to smallest). Servers that don't have any of the missing changes are dropped from the list. If one server doesn't have all the necessary changes, Exchange selects the next server in the sorted list and sends a backfill request to that server as well. This process is repeated until all of the changes are requested. If the selected server doesn't respond to the backfill request, the database marks that server as unavailable and repeats the selection process. Servers marked as unavailable move to the end of the list.

Status Requests and Status Messages

In addition to the status information in each replication message, Exchange uses status requests and status messages to determine whether public folders must issue backfill requests. A public folder database sends a status request under the following circumstances:

The database is notified of a change to the list of databases that hold replicas of a folder. For example, if you add a database to the list or remove a database from the list, Exchange replicates this change by using hierarchy update messages. In this case, the database sends a status request that requires every database that contains a replica of the folder to respond. A new database has started for the first time. In this case, the database requests the status of the public folder hierarchy. The database sends a status request that requires every database that supports the public folder tree to respond. A database that has been restored by using Windows Server Backup starts for the first time after the restore completes. In this case, the database requests the status of the public folder hierarchy and all of the folders for which the database contains content replicas. This status request lists two or three databases as required responders. Required responders are databases that support this hierarchy and, according to an internal selection process, are dependable sources of folder content. To indicate the current state of a particular folder on the sending database, the public folder database sends a status message to another database under the following circumstances:

In response to a status request sent by another database. The status message is sent only to the requesting database and only if the following are true: The database that received the status request is in the requests list of required responders. The replication state table indicates that the database that received the status request has updates that are missing from the database that sent the request. If there have been no subsequent updates 24 hours after the most recent update to a folder was received. Each time the database receives an update for a specific folder, the timer is reset to 24 hours. This status message is sent to the other public folder databases that contain replicas of the updated folder. If a public folder database receives a status message indicating that the sending database has more recent information about the folder, the receiving database creates a backfill request. If the change numbers are shown to be equal (or the change numbers on the receiving server are more recent), no action is taken. For example, when a new public folder database starts for the first time, it sends status request messages to each database that supports the public folder hierarchy. Each database responds with information about the status of the hierarchy (as tracked by that database). The new database uses this information to identify which replicas (if any) it should have. The new database can then send backfill requests as needed to fill in the replica content. Return to top

Examples of Replication Cycles

The following figure illustrates a simplified two-server scenario that shows the sequence of events that occurs when you add a content replica to a public folder

database. This action adds the public folder database to the folder's replica list. Note that the sequence of steps depends on factors such as the timing of the replication intervals and the routing topology.

The details of the process are as follows:

1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

Working on ExServ01, an administrator adds ExServ01 to a folder's replica list. ExServ01 sends a hierarchy message. ExServ02 adds ExServ01 to the local copy of the folder's replica list. ExServ01 sends a status request to ExServ02. ExServ02 sends a status message to ExServ01 that includes the full CNSet of the folder. ExServ01 determines that all the folder content is missing and records the appropriate entries in the backfill array. If the content is still missing when the backfill time-out elapses, ExServ01 creates a backfill request and sends it to ExServ02. ExServ02 compiles the content messages and sends them to ExServ01. ExServ01 uses the incoming content messages to update the folder content and related tracking information. If change numbers still appear to be missing, ExServ01 waits 24 hours, and then sends an updated backfill request. If a server other than ExServ02 is available, ExServ01 might send the request to that server.

The following figure illustrates a simplified two-server scenario that shows the sequence of events that occur when you remove a replica from a public folder database. (This action removes the public folder database from the folder's replica list.) Note that the sequence of steps depends on factors such as the number of servers in the topology.

The details of the process are as follows:

1. Working on ExServ01, an administrator removes ExServ01 from a folder's replica list. 2. ExServ01 marks its replica (the copy of the folder on ExServ01) as delete pending. Clients can no longer access the folder by using this database. 3. ExServ01 sends a hierarchy message. 4. ExServ02 updates its copy of the folder's replica list to show that the folder is in the delete pending state on ExServ01. ExServ02 no longer refers clients that are looking for this folder to ExServ01. 5. ExServ01 sends a status request to ExServ02. 6. ExServ02 sends a status message to ExServ01. If the replica on ExServ02 isn't up to date, ExServ02 places the appropriate entries in the backfill array. Within five minutes, ExServ02 sends the corresponding backfill request to ExServ01. 7. ExServ01 checks that the folder replica on ExServ02 contains all of the information that the delete pending replica does. If it doesn't, ExServ01 sends the appropriate content updates and returns to Step 5. Otherwise, ExServ01 continues to Step 8. This process ensures that as long as other replicas exist, deleting a single replica doesn't result in a loss of content. 8. ExServ01 marks its replica as delete now. The next maintenance cycle will remove the replica from ExServ01. 9. ExServ01 sends a hierarchy message. 10. ExServ02 removes ExServ01 from its copy of the folder's replica list. Return to top

Best Practices for Implementing Replication

Public folder replication in Exchange can be a resource-intensive operation. Replication requires network, CPU, and disk resources to operate. By implementing a solution that enables efficient public folder replication, especially in organizations with heavy public folder usage, you may greatly improve network, CPU, and disk load in your Exchange organization. Generally, it's a best practice to minimize replication across the organization. By minimizing replication, you minimize the amount of data that travels over your network. Additionally, by minimizing replication, you can help make sure that multiple users are less likely to access different versions of data on multiple replicas. However, you should note that by minimizing replication, you decrease availability of the public folder data because fewer replicas of the folder are available to clients if a public folder database fails. If availability on a large scale is required for data in a specific public folder, you may require more replication. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Public Folder Referrals

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-01-27 When a user accesses a public folder by using a MAPI client application, such as Microsoft Outlook, the public folder database determines which public folder replica the client should access. This process is called referral. If a replica of the requested content exists on the server running Microsoft Exchange that serves the client request, the client accesses the local replica. When a user connects to a public folder database that doesn't contain a copy of the public folder content that the user wants, the user is redirected to another public folder database that has a copy of the content. As illustrated in the following figure, you can create a custom cost list for public folder referral to control this redirect traffic. Note: Public folder referrals have an associated cost number. The numbers range from 1 through 100. This cost number is used to optimize message flow. Specifically, e-mail messages are routed according to lowest cost number. If two or more routes are available with the same cost, the load is distributed as equally as possible between them. This cost is also used to calculate the most appropriate route that the client application can use to access public folders on remote servers. Using the default referral configuration, Exchange Server 2010 follows the structure of your organization's Active Directory site to locate an appropriate server. However, to modify the flow of user traffic, Active Directory site administrators can redirect this configuration by specifying whether to allow referrals over certain connectors. For Exchange 2010 servers, you can also specify a list of referral servers and assign routing costs to each server to redirect server traffic. For example, you can limit referrals to a single Active Directory site or only allow referrals between certain servers in each Active Directory site. Looking for management tasks related to public folders? See Managing Public Folders.

How Referrals Are Determined

When a user connects to Exchange and uses a MAPI client application to request access to a public folder, Exchange locates a content replica of the public folder by using information supplied by the public folder database associated with the user's mailbox database. The public folder database retrieves the replica list of the requested folder and, if necessary, retrieves routing and cost information from Active Directory Sites and Services. Exchange uses the process shown in the following figure to locate a content replica.

The details of the process are as follows:

1. The MAPI client connects to the user's mailbox database to access the user's private folders. The MAPI client also connects to the user's mailbox to retrieve the default public folder database for information about the public folder hierarchy. For more information about how to set the default public folder database, see Change the Default Public Folder Database for a Mailbox Database. 2. The MAPI client attempts to read the content for a specific public folder. Initially, the default public folder database is queried for the content. If that database is a content replica for the folder in question, the process is complete. 3. If there is no replica on the default public folder database, Exchange returns a list of replicas to the client, sorted by that servers perspective of connection costs to each of the other listed content replicas. Connection costs are determined by querying Active Directory Sites and Services for the site connector cost information of the other Mailbox servers in the organization on which a public folder database resides. Alternatively, you can specify costs to other servers by providing a custom override list to the public folder database. The list returned to the client doesn't include servers for which the cost is greater than 500.

Note: Cost information is refreshed once every hour. Therefore, any changes to Active Directory site costs aren't available for up to one hour. In addition, any changes in the public folder custom list, including its initial configuration or complete removal, isn't available for up to one hour. Servers that aren't listed in the custom list of the public folder will never receive referrals from the server that has the custom list. 4. The MAPI clients attempt to access each replica in the list by connecting to the server, attempting to locate the folder, and then attempting to read the folder's content. 5. If a failure occurs, the client attempts to access the next replica server in the list until the client has attempted to access all replica servers in the custom list. Note: The MAPI client doesn't refresh its connection unless its current connection is terminated. In other words, if a preferred or low-cost replica can't be reached, the client attempts to access the next replica in the list, which may be expensive to reach. If the low-cost server becomes available, the MAPI client doesn't redirect the connection to the low-cost replica until the user logs off and then logs back on to the MAPI client.

Assigning Cost
Although Exchange administrators can create public folder referrals and site costs, we don't recommend that you do this because the maximum public folder referral cost that Exchange administrators can set for a public folder database is 100. By setting the maximum referral cost for a server to 100, the server may still be used for referrals. Instead, public folder referrals and site costs should be determined by an administrator who is a member of the Domain Admins group or the Enterprise Admins group in Active Directory. In Active Directory Sites and Services, a user who has Domain Admin or Enterprise Admin permissions can set the public folder referral cost up to 500. This higher cost number helps ensure that a server won't be used for referrals. Note: To create efficient public folder referrals, you must understand the structure of your organization's Active Directory site. For more information about routing, Active Directory sites, routing costs, and Send and Receive connectors, see Understanding Message Routing. For detailed steps about how to configure an Exchange 2010 server to use a specific list of servers and costs for referrals, see Configure Public Folder Referrals.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Quota Messages

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-10-13 A quota message is an e-mail message that's automatically sent by Microsoft Exchange to the owners of a mailbox or a public folder when a size limit (called a storage quota) for the mailbox or public folder is exceeded. You can use the New-SystemMessage, Get-SystemMessage, Set-SystemMessage, and Remove-SystemMessage cmdlets in the Exchange Management Shell to view built-in quota messages or to create, view, modify, or remove customized quota messages.

Quota Messages in Exchange 2010 SP1

Exchange 2010 SP1 introduces a flag that controls whether a mailbox is checked to see if its size is equal to or greater than 50% of the Prohibit send quota.As a result, if the Issue Warning quota is set to a value less than 50% of the Prohibit send quota, the warning message associated with the Issue warning quota wont be sent to the user. For example, if a mailbox has a size limit of 10 MB, and you set the Issue warning quota to 3 MB and the Prohibit send quota to 8 MB, the user wont ever receive the warning specified by the Issue warning quota because the Issue warning quota limit isnt equal to or greater than 50% of the Prohibit send quota. Instead, the user will receive only the message associated with the Prohibit send quota in this case, when the users mailbox size reaches 8 MB. In addition, the flag is cleared after you run the Set-MailboxDatabase cmdlet with the QuotaNotificationSchedule parameter. When you run that command, the mailbox wont be checked again until the flag is reset. Flags are reset when a message is saved in the mailbox or when a message is sent to or from the mailbox.At that point if the mailbox size is greater than 50% of the Prohibit send quota, the flag is reset and the mailbox is checked at the time specified by the QuotaNotificationSchedule parameter.

Storage Quotas
A storage quota is a storage size limit for a mailbox or a public folder. You can use the Exchange Management Console (EMC) or the Shell to view or set the storage quotas for all of the mailboxes or public folders in a database. You can also use the EMC or the Shell to set storage quotas on a per-mailbox basis, thereby overriding the storage quotas that are set at the database level. However, storage quotas for individual public folders can be viewed or set only in the Shell. For more information about viewing and configuring storage quotas, see the following topics:

Configure Mailbox Database Properties Configure Storage Quotas for a Mailbox Configure Archive Quotas for a Personal (On-Premises) Archive Set-MailboxDatabase Set-Mailbox Configure Public Folder Properties Set-PublicFolderDatabase Set-PublicFolder

Quota Messages
By default, Exchange sends a quota message to mailbox or public folder owners when a:

Mailbox, personal archive, or public folder exceeds its Issue warning limit (the lowest storage quota). Mailbox exceeds its Prohibit send limit or a public folder exceeds its Prohibit post limit (the middle storage quota). Mailbox exceeds its Prohibit send and receive quota or a personal archive exceeds its archive quota (the highest storage quota). Quota messages for mailboxes are sent to mailbox owners. If a mailbox is owned by a security group (that is, if it's a shared mailbox), quota messages are sent to the security group. Quota messages for public folders are sent to every public folder owner. Owners of mailboxes and public folders can be users, contacts, or security groups. Quota messages are sent with high importance and aren't subject to storage quotas. They're always delivered, even if the recipient's mailbox is full. Exchange can generate quota messages in many languages. For a list of the supported language locales that are available for use with quota messages, see Supported Locales for Use with System Messages.

Quota Message Format

There are seven types of quota messages: four for mailboxes and three for public folders. All quota messages include the following:

Text Microsoft Exchange in the From field Brief, non-customizable description of the situation in the Subject field Customizable message in the message body Graphical representation of the storage quota and the amount of storage used in the message body (except for mailboxes or public folders of unlimited size)

Default Quota Messages

The following tables list the subject and the default message text for the seven default English quota messages (four for mailboxes and three for public folders). The default message can be customized, but the subject text can't.

Note: There are no specific archive quota messages. If a user's archive is meeting or exceeding any quotas, they will receive mailbox quota messages.

Mailbox quota and archive quota messages

Event Subject of message Your mailbox is becoming too large Your mailbox is almost full Default message text

Mailbox of unlimited size exceeds its Issue warning quota

Please reduce your mailbox size. Delete any items you don't need from your mailbox and empty your Deleted Items folder.

Mailbox of limited size exceeds its Issue warning quota Important: The message associated with the Issue warning quota wont be sent to the user unless the value of the quota is greater than 50% of the value specified in the Prohibit send quota. For example, if you set the Prohibit send quota to 8 MB, you must set the Issue warning quota to at least 4 MB. If you dont, the Issue warning quota message wont be sent.

Please reduce your mailbox size. Delete any items you don't need from your mailbox and empty your Deleted Items folder.

Mailbox of limited size exceeds its Prohibit send quota

Your mailbox is full

Your mailbox can no longer send messages. Please reduce your mailbox size. Delete any items you don't need from your mailbox and empty your Deleted Items folder. Your mailbox can no longer send or receive messages. Please reduce your mailbox size. Delete any items you don't need from your mailbox and empty your Deleted Items folder.

Mailbox of limited size exceeds its Prohibit send and receive quota

Your mailbox is full

Public folder quota messages

Event Public folder of unlimited size exceeds its Issue warning quota Public folder of limited size exceeds its Issue warning quota Public folder of limited size exceeds its Prohibit post quota Subject of message Your public folder is becoming too large Your public folder is almost full Your public folder is full Default message text Please reduce the size of your public folder by deleting any items you don't need.

Please reduce the size of your public folder by deleting any items you don't need.

Users can no longer post items to this folder. Please reduce the size of your public folder by deleting any items you don't need.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Recipients
Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-02-24 The people and resources that send and receive messages are the core of any messaging and collaboration system. In an Exchange organization, these people and resources are referred to as recipients. A recipient is any mail-enabled object in Active Directory to which Exchange can deliver or route messages.

Recipient Types
Microsoft Exchange Server 2010 includes several explicit recipient types. Each recipient type is represented by a unique icon in the Exchange Management Console (EMC) and a unique name in the RecipientTypeDetails property in the Exchange Management Shell. The use of explicit recipient types has the following benefits:

At a glance, you can differentiate between various recipient types. You can search, sort, and filter by each recipient type. You can more easily perform bulk management operations for each recipient type. You can more easily view recipient properties because the EMC uses the recipient types to render different property pages. For example, the resource capacity is displayed for a conference room mailbox, but isn't present for a user mailbox. The following table lists the available recipient types. All these recipient types are discussed in more detail later in this topic.

Exchange 2010 recipient types

Recipient type Dynamic distribution group Equipment mailbox Legacy mailbox Linked mailbox Mail contact Description A distribution group that uses recipient filters and conditions to derive its membership at the time messages are sent.

A resource mailbox that's assigned to a non-location specific resource, such as a portable computer projector, microphone, or a company car. Equipment mailboxes can be included as resources in meeting requests, providing a simple and efficient way of utilizing resources for your users. A mailbox that resides on a server running Exchange Server 2003. A mailbox that's assigned to an individual user in a separate, trusted forest. A mail-enabled Active Directory contact that contains information about people or organizations that exist outside the Exchange organization. Each mail contact has an external e-mail address. All messages sent to the mail contact are routed to this external e-mail address. A mail contact that represents a recipient object from another forest. Mail forest contacts are typically created by Microsoft Identity Integration Server (MIIS) synchronization. Important: Mail forest contacts are read-only recipient objects that are updated only through MIIS or similar custom synchronization. You can't use the EMC or the Shell to remove or modify a mail forest contact.

Mail forest contact

Mail user

A mail-enabled Active Directory user that represents a user outside the Exchange organization. Each mail user has an external e-mail address. All messages sent to the mail user are routed to this external e-mail address. A mail user is similar to a mail contact, except that a mail user has Active Directory logon credentials and can access resources. A mail-enabled Active Directory global or local group object. Mail-enabled non-universal groups were discontinued in Exchange Server 2007 and can exist only if they were migrated from Exchange 2003 or earlier versions of Exchange. You can't use Exchange 2010 to create non-universal distribution groups. An Exchange public folder that's configured to receive messages.

Mail-enabled non-universal group Mail-enabled public folder Mail-enabled universal distribution group Mail-enabled universal security group Microsoft Exchange recipient Room mailbox

A mail-enabled Active Directory distribution group object that can be used only to distribute messages to a group of recipients.

A mail-enabled Active Directory security group object that can be used to grant access permissions to resources in Active Directory and can also be used to distribute messages.

A special recipient object that provides a unified and well-known message sender that differentiates system-generated messages from other messages. It replaces the System Administrator sender used for system-generated messages in earlier versions of Exchange. To learn more, see Understanding the Microsoft Exchange Recipient. A resource mailbox that's assigned to a meeting location, such as a conference room, auditorium, or training room. Room mailboxes can be included as resources in meeting requests, providing a simple and efficient way of organizing meetings for your users.

Shared mailbox User mailbox

A mailbox that's not primarily associated with a single user and is generally configured to allow logon access for multiple users. A mailbox that's assigned to an individual user in your Exchange organization. It typically contains messages, calendar items, contacts, tasks, documents, and other important business data. New in Exchange 2010, a remote mailbox consists of a mail-enabled user that exists in the on-premises Active Directory and an associated mailbox that exists in the cloud-based service. New in Exchange 2010, a linked user is a user that resides in one forest while their mailbox resides in another forest.

Remote mailbox

Linked user

Mailboxes
Mailboxes are the most common recipient type used by information workers in an Exchange organization. Each mailbox is associated with an Active Directory user account. The user can use the mailbox to send and receive messages, and to store messages, appointments, tasks, notes, and documents. Mailboxes are the primary messaging and collaboration tool for the users in your Exchange organization.

Mailbox Components
Each mailbox consists of an Active Directory user and the mailbox data that's stored in the Exchange mailbox database (as shown in the following figure). All configuration data for the mailbox is stored in the Exchange attributes of the Active Directory user object. The mailbox database contains the actual data that's in the mailbox associated with the user account. Important: When you create a mailbox for a new or existing user, the Exchange attributes required for a mailbox are added to the user object in Active Directory. The associated mailbox data isn't created until the mailbox either receives a message or the user logs on to it.

Warning: If you remove a mailbox, the mailbox data stored in the Exchange mailbox database is marked for deletion and the associated user account is also deleted from Active Directory. To retain the user account and delete only the mailbox data, you must disable the mailbox.

Mailbox Types
Exchange 2010 supports the following mailbox types:

User mailboxes User mailboxes are assigned to individual users in your Exchange organization. User mailboxes provide your users with a rich collaboration platform. They can send and receive messages, manage their contacts, schedule meetings, and maintain a task list. Users can also have voice mail messages delivered to their mailboxes. User mailboxes are the most commonly used mailbox type and are typically the mailbox type assigned to users in your organization. Linked mailboxes Linked mailboxes are mailboxes that are accessed by users in a separate, trusted forest. Linked mailboxes may be necessary for organizations that deploy Exchange in a resource forest. The resource forest scenario allows an organization to centralize Exchange in a single forest, while allowing access to the Exchange organization with user accounts in one or more trusted forests. As stated earlier, every mailbox must have a user account associated with it. However, the user account that accesses the linked mailbox doesn't exist in the forest where Exchange is deployed. Therefore, a disabled user account that exists in the same forest as Exchange is associated with each linked mailbox. The following figure illustrates the relationship between the linked user account used to access the linked mailbox and the disabled user account in the Exchange resource forest associated with the linked mailbox.

Remote mailboxes When you create a remote mailbox, the mail-enabled user is created in your on-premises Active Directory. Directory synchronization, if it's configured, automatically synchronizes this new user object to the cloud-based service, which then converts it to a user mailbox. You can create remote mailboxes as regular user mailboxes or as resource mailboxes for meeting rooms and equipment. Shared mailboxes Shared mailboxes aren't primarily associated with individual users and are generally configured to allow logon access for multiple users.

Although it's possible to grant additional users the logon rights to any mailbox type, shared mailboxes are dedicated for this functionality. The Active Directory user associated with a shared mailbox must be a disabled account. After you create a shared mailbox, you must grant permissions to all users that require access to the shared mailbox. Important: You can only use the Shell to manage shared mailboxes. Management tasks include creating, removing, enabling, and disabling. After you create a shared mailbox, you can use the EMC for some tasks such as viewing, modifying, or moving the shared mailboxes. We recommend that you use resource mailboxes or Microsoft SharePoint Portal Server portals for collaboration instead of shared mailboxes. To learn more about converting a shared mailbox to a resource mailbox, see Convert a Mailbox. Legacy mailboxes Legacy mailboxes are mailboxes that reside on servers running Exchange 2003. You can manage legacy mailboxes by using the EMC or the Shell. However, not all Exchange 2010 features will apply to these mailboxes. Resource mailboxes Resource mailboxes are special mailboxes designed to be used for scheduling resources. Like all mailbox types, a resource mailbox has an associated Active Directory user account, but it must be a disabled account. The following are the resource mailbox types: Room mailboxes These are resource mailboxes that are assigned to meeting locations, such as conference rooms, auditoriums, and training rooms. Equipment mailboxes These are resource mailboxes that are assigned to non-location specific resources, such as portable computer projectors, microphones, or company cars. You can include both types of resource mailboxes in meeting requests, providing a simple and efficient way to utilize resources for your users. You can configure resource mailboxes to automatically process incoming meeting requests based on the resource booking policies that are defined by the resource owners. For example, you can configure a conference room to automatically accept incoming meeting requests except recurring meetings, which can be subject to approval by the resource owner. To learn more about using resource mailboxes, see Managing Resource Mailboxes and Scheduling.

System Mailboxes
System mailboxes are created by Exchange in the root domain of the Active Directory forest during installation. Users or administrators can't log on to these mailboxes. System mailboxes are created for Exchange 2010 features such as message approval and Multi-Mailbox Search. This table lists information about system mailboxes as they're displayed in Active Directory.

Mailbox Discovery Message Approval

Common name (CN) SystemMailbox {e0dc1c29-89c3-4034-b678-e6c29d823ed9} SystemMailbox {1f05a927-xxxx- xxxx - xxxx -xxxxxxxxxxxx} where x is a randomly assigned number FederatedEmail 4c1f4d8b-8179-4148-93bf-00a95fa1e042

Federated E-mail

If you want to decommission the last Exchange 2010 Mailbox server in your organization, you should first disable these system mailboxes by using the DisableMailbox cmdlet. When you decommission a Mailbox server that contains these system mailboxes, you should move them to another Mailbox server to make sure that you don't lose functionality.

Planning for Mailboxes

Mailboxes are created in mailbox databases on Exchange servers that have the Mailbox server role installed. To help provide a reliable and effective platform for your mailbox users, detailed planning for the deployment of Mailbox servers and databases is essential. To learn more about planning for Mailbox servers and databases, see the following topics:

Planning Roadmap for New Deployments Exchange 2003 - Planning Roadmap for Upgrade and Coexistence Exchange 2007 - Planning Roadmap for Upgrade and Coexistence Managing Mailbox Databases Managing Mailbox Servers

Distribution Groups
Distribution groups are mail-enabled Active Directory group objects that are primarily used for distributing messages to multiple recipients. Any recipient type can be a member of a distribution group. Important: Note the terminology differences between Active Directory and Exchange 2010. In Active Directory, a distribution group refers to any group that doesn't have a security context, whether it's mail-enabled or not. In Exchange 2010, all mail-enabled groups are referred to as distribution groups, whether they have a security context or not. Exchange supports the following types of distribution groups:

Mail-enabled universal distribution groups These are Active Directory distribution group objects that are mail-enabled. They can be used only to distribute messages to a group of recipients. Mail-enabled universal security groups These are Active Directory security group objects that are mail-enabled. They can be used to grant access permissions to resources in Active Directory and can also be used to distribute messages. Mail-enabled non-universal groups These are Active Directory global or local group objects that are mail-enabled. You can create or mail-enable only universal distribution groups. You may have mail-enabled groups that were migrated from previous versions of Exchange that aren't universal groups. These groups can still be managed by using the EMC or the Shell.

Note: To convert a domain-local or a global group to a universal group, you can use the Set-Group cmdlet in the Shell. For more information about the changes from Exchange Server 2007 to Exchange Server 2010 that affect group management, see the Distribution Groups section in the New Mailbox and Recipient Functionality topic.

Dynamic Distribution Groups

Dynamic distribution groups are distribution groups whose membership is based on specific recipient filters rather than a defined set of recipients. Unlike regular distribution groups, the membership list for dynamic distribution groups is calculated each time a message is sent to them, based on the filters and conditions that you specify. When an e-mail message is sent to a dynamic distribution group, it's delivered to all recipients in the organization that match the criteria defined for that dynamic distribution group. Important: A dynamic distribution group includes any recipient in Active Directory that has attributes that match the group's filter at the time a message is sent. If a recipient's properties are modified to match the group's filter, that recipient could inadvertently become a group member and start receiving messages that are sent to the dynamic distribution group. Well-defined, consistent account provisioning processes can reduce the chances of this issue occurring. To help you create recipient filters for dynamic distribution groups, you can use precanned filters. A precanned filter is a commonly used filter that you can use to meet a variety of recipient-filtering criteria. You can use these filters to specify the recipient types that you want to include in a dynamic distribution group. In addition, you can also specify a list of conditions that the recipients must meet. You can create precanned conditions based on the following properties:

Custom attributes 115 State or province Company Department You can also specify conditions based on recipient properties other than those previously listed. To do this, you must use the Shell to create a custom query for the dynamic distribution group. Keep in mind that the filter and condition settings for dynamic distribution groups that have custom recipient filters can be managed only by using the Shell. For an example of how to create a dynamic distribution group by using a custom query, see Create a Dynamic Distribution Group. Note: In the EMC, you use the Distribution Group node under Recipient Configuration to manage dynamic distribution groups. There isn't a separate node for dynamic distribution groups.

Mail Contacts
Mail contacts typically contain information about people or organizations that exist outside your Exchange organization. Mail contacts can appear in the global address list (GAL) and other address lists, and can be added as members to distribution groups. Each contact has an external e-mail address, and all e-mail messages that are sent to a contact are automatically forwarded to that address. Contacts are ideal for representing people external to your Exchange organization who don't need access to any internal resources. The following are mail contact types:

Mail contacts These are mail-enabled Active Directory contacts that contain information about people or organizations that exist outside your Exchange organization. Mail forest contacts These represent recipient objects from another forest. These contacts are typically created by MIIS synchronization. Mail forest contacts are read-only recipient objects that can be updated or removed only by means of synchronization. You can't use Exchange management interfaces to modify or remove a mail forest contact.

Mail Users
Mail users are similar to mail contacts. Both have external e-mail addresses, both contain information about people outside your Exchange organization, and both can be displayed in the GAL and other address lists. However, unlike a mail contact, mail users have Active Directory logon credentials and can access resources to which they are granted permission. If a person external to your organization requires access to resources on your network, you should create a mail user instead of a mail contact. For example, you may want to create mail users for short-term consultants who require access to your server infrastructure, but who will use their own external e-mail addresses. Another scenario is to create mail users in your organization for users who you don't want to maintain an Exchange mailbox. For example, after an acquisition, the acquired company may maintain their separate messaging infrastructure, but may also need access to resources on your network. For those users, you may want to create mail users instead of mailbox users. Note: In the EMC, you use the Mail Contact node under Recipient Configuration to manage mail users. There isn't a separate node for mail users.

Mail-Enabled Public Folders

Public folders are intended to serve as a repository for information shared among many users. Mail-enabling a public folder provides an extra level of functionality to users. In addition to being able to post messages to the folder, users can send e-mail messages to, and sometimes receive e-mail messages from, the public folder. Each mail-enabled folder has an object in Active Directory that stores its e-mail address, address book name, and other mail-related attributes. You can manage public folders by using either the Shell or the Public Folder Management Console. To access the Public Folder Management Console, click the

Toolbox node in the EMC. For more information about managing mail-enabled public folders, see Configure Public Folder Properties.

Microsoft Exchange Recipient

The Microsoft Exchange recipient is a special recipient object that provides a unified and well-known message sender that differentiates system-generated messages from other messages. It replaces the System Administrator sender that was used for system-generated messages in earlier versions of Exchange. The Microsoft Exchange recipient isn't a typical recipient object, such as a mailbox, mail user, or mail contact, and it isn't managed by using the typical recipient tools. However, you can use the Set-OrganizationConfig cmdlet in the Shell to configure the Microsoft Exchange recipient. To learn more about the Microsoft Exchange recipient, see Understanding the Microsoft Exchange Recipient. Note: When system-generated messages are sent to an external sender, the Microsoft Exchange recipient isn't used as the sender of the message. Instead, the e-mail address specified by the ExternalPostmasterAddress parameter in the Set-TransportConfig cmdlet is used. For more information about the external postmaster address, see Configure the External Postmaster Address.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Automatic Mailbox Distribution

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-07-07 When you create or move a mailbox, or mail-enable an existing user, that mailbox needs to be stored in a mailbox database. In previous versions of Microsoft Exchange, you needed to specify the mailbox database when you performed one of those operations. With Microsoft Exchange Server 2010, you have the option of letting Exchange choose the database for you using automatic mailbox distribution. With automatic mailbox distribution, Exchange looks at the mailbox databases in your organization, excludes databases that aren't suitable using criteria discussed later in this topic, and then randomly chooses a database where the mailbox should be located. This process randomly distributes mailboxes across all of the suitable mailbox databases in your organization. Automatic distribution is used when you don't specify the Database parameter on the New-Mailbox and Enable-Mailbox cmdlets or the TargetDatabase parameter on the New-MoveRequest cmdlet. Note: Automatic mailbox distribution is performed only when a mailbox is created on an Exchange 2010 server, moved to an Exchange 2010 server, or when a user is mailenabled. The New-Mailbox, New-MoveRequest, and Enable-Mailbox cmdlets must be run from a server running Exchange 2010. Exchange doesn't redistribute mailboxes to distribute load across databases automatically based on server load. The following process is used to find a suitable mailbox database where a new or moved mailbox should be located:

1. Exchange retrieves a list of all mailbox databases in the Exchange 2010 organization. 2. Any mailbox database that's marked for exclusion from the distribution process is removed from the available list of databases. You can control which databases are excluded. For more information, see Exclude Databases from Automatic Distribution later in this topic. 3. Any mailbox database that's outside of the database management scopes applied to the administrator performing the operation is removed from the list of available databases. For more information, see Database Scopes later in this topic. 4. Any mailbox database that's outside of the local Active Directory site where the operation is being performed is removed from the list of available databases. 5. From the remaining list of mailbox databases, Exchange chooses a database randomly. If the database is online and healthy, the database is used by Exchange. If it's offline or not healthy, another database is chosen at random. If no online or healthy databases are found, the operation fails with an error. The process of selecting a mailbox database is performed by the Mailbox Resources Management Agent cmdlet extension agent. The Mailbox Resources Management Agent is one of several cmdlet extension agents that extend the functionality of running cmdlets. For more information about cmdlet extension agents, see Understanding Cmdlet Extension Agents. If you never want mailboxes to be distributed automatically, you can disable the Mailbox Resources Management Agent. When you disable the agent, the change is applied to the entire Exchange 2010 organization. For more information about how to disable cmdlet extension agents, see Disable a Cmdlet Extension Agent.

Exclude Databases from Automatic Distribution

By default, all online and healthy mailbox databases on Exchange 2010 servers in the local Active Directory site can be chosen by automatic mailbox distribution to store a new or moved mailbox. However, you might want to exclude some databases from the distribution process for various reasons. For example, you may designate a mailbox database as a journaling database in which only mailboxes you manually specify should be located. Or you might want to temporarily remove a database from rotation to perform scheduled maintenance. Exchange 2010 gives you the option to either permanently or temporarily exclude databases from the exclusion process. Every Exchange 2010 mailbox database has the two following properties that can be set using the Set-MailboxDatabase cmdlet:

IsExcludedFromProvisioning Use this property if you want to indicate that the database should be permanently excluded from automatic mailbox distribution. IsSuspendedFromProvisioning Use this property if you want to indicate that the database should be temporarily excluded from automatic mailbox distribution. Both properties have two valid values, $True and $False. The default value for each is $False. The property you choose is purely for your information. Setting either property to $True has the same result of excluding the database from the automatic distribution process. Both properties must be set to $False for a mailbox database to be included in the automatic distribution process. Exchange 2010 provides these two properties for excluding a mailbox database from automatic distribution so that you can easily identify the databases that have been permanently excluded from automatic distribution and which have been temporarily excluded. To set a mailbox database as permanently excluded from automatic distribution, use the following command:

Set-MailboxDatabase <database name> -IsExcludedFromProvisioning $True

To set a mailbox database as temporarily excluded from automatic distribution, use the following command:

Set-MailboxDatabase <database name> -IsSuspendedFromProvisioning $True

When a mailbox database is excluded from automatic distribution, the only way to create a mailbox in, or move a mailbox to, the database is to use the Database parameter on the New-Mailbox and Enable-Mailbox cmdlets or the TargetDatabase parameter on the New-MoveRequest cmdlet. If you want to make an excluded mailbox database available for selection in the automatic distribution process, set both properties to $False.

Database Scopes
Database management scopes are an additional level of control over the automatic mailbox distribution process that's been added to Microsoft Exchange Server 2010 Service Pack 1 (SP1). If a mailbox database is online and healthy, it's in the local Active Directory site, and it isn't excluded from the automatic distribution process, Exchange 2010 SP1 checks to see if the mailbox database is included in the database scope applied to the administrator running the cmdlet. If it's included in the database scope, it's included in the list of databases available to that administrator. Database scopes are part of the Role Based Access Control (RBAC) permissions model. For more information about RBAC and database scopes, see the following topics:

Understanding Role Based Access Control Understanding Management Role Scopes Database scopes can be useful if you have many mailbox databases in your local Active Directory site that are available to automatic distribution, but you want to limit which databases can be used by certain sets of administrators. For example, your Exchange 2010 SP1 servers may serve several agencies but you only want to allow each agency to create or move mailboxes to mailbox databases that are allocated to them. By default, all administrators in an Exchange 2010 SP1 organization can see all of the mailbox databases in the organization. To limit the databases that they can see, and therefore limit the databases they can potentially create mailboxes in or move mailboxes to, you must do the following:

1. Create a custom database management scope using the New-ManagementScope cmdlet that includes only the mailbox databases you want the administrator to use. 2. Associate the new database scope with a management role assignment in one of the following ways: Add the new database scope to an existing management role assignment using the CustomConfigWriteScope parameter on the SetManagementRoleAssignment cmdlet. The database scope is now applied to the management role group, universal security group (USG), or user assigned the role assignment. Create a management role assignment using the New-ManagementRoleAssignment cmdlet and use the CustomConfigWriteScope parameter to specify the new database scope. You can create a role assignment between a management role and a role group, USG, or user. 3. If you created a role assignment to a role group or USG, add users to the role group or USG so that the role assignment and database scope are applied to the users. 4. If applicable, remove the user (or users who are members of role groups or USGs you created in the preceding steps) you assigned the new role assignment to from any other role groups or USGs that might be assigned a database scope that contains databases you don't want them to access. 5. Verify that the administrators have access only to the databases they should have access to. After you complete these steps, the administrators that are assigned role assignments with the database scopes you created will only be able to create mailboxes in or move mailboxes to the databases you specified. For more information about how to use database scopes to limit which mailbox databases are available to administrators, see Control Automatic Mailbox Distribution Using Database Scopes.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Custom Attributes

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2013-03-14 Microsoft Exchange Server 2010 and Exchange Server 2007 include 15 extension attributes. You can use these attributes to add information about a recipient, such as an employee ID, organizational unit (OU), or some other custom value for which there isn't an existing attribute. These custom attributes are labeled in Active Directory as msExch-Extension-Attribute1 through ms-Exch-Extension-Attribute15. In the Exchange Management Shell, the corresponding parameters are CustomAttribute1 through CustomAttribute15. These attributes aren't used by any Exchange components. They can be used to store Active Directory data without having to extend the Active Directory schema. In Microsoft Exchange Server 2003 and earlier versions, if you wanted to store this information in Active Directory, you had to create an attribute by extending the Active Directory schema. Schema extension requires planning, procuring object identifiers (OIDs) for new attributes, and testing the extension process in a test environment before you implement it in a production environment. In Exchange 2010 and Microsoft Exchange Server 2007, user-defined Active Directory schema extensions can't be used in recipient filters used by address lists, e-mail address policies, and dynamic distribution groups. Important: In Exchange 2003, you can create user-defined Active Directory schema extensions. However, in Exchange 2010, you can't use Exchange 2003 user-defined schema extensions as filterable properties. If your organization has user-defined schema extensions, we recommend that you use the 15 custom attributes defined by Exchange 2010 for each recipient. However, if the 15 custom attributes defined by Exchange don't meet the needs of your organization, we recommend that you don't upgrade objects that use user-defined schema extensions. Contents Advantages of Custom Attributes Multivalued Custom Attributes Custom Attributes Examples Custom Attributes Example with the ConditionalCustomAttributes Parameter

Advantages of Custom Attributes

Some of the advantages of using custom attributes are:

You avoid extending the Active Directory schema. The attributes are created by Exchange Setup. You can use the Exchange Management Console (EMC) or the Exchange Management Shell to manage the attributes. You don't have to build custom controls or write scripts to populate and display these attributes. The attributes are filterable properties that can be used in the Filter parameter with recipient cmdlets such as Get-Mailbox. They can also used in the EMC and in the Shell to create filters for e-mail address policies, address lists, and dynamic distribution groups. Return to top

Multivalued Custom Attributes

In Microsoft Exchange 2010 Service Pack 2 (SP2), five multivalued custom attributes were added to let you store additional information for mail recipients if the traditional custom attributes dont meet your needs. The ExtensionCustomAttribute1 through ExtensionCustomAttribute5 parameters can hold up to 1,300 values each. You can specify multiple values as a comma-delimited list. The following cmdlets support these new parameters:

Set-DistributionGroup Set-DynamicDistributionGroup Set-Mailbox Set-MailContact Set-MailPublicFolder Set-RemoteMailbox For more information about multivalued properties, see Modifying Multivalued Properties.

Custom Attribute Examples

In many Exchange deployments, creating an e-mail address policy for all recipients in an OU is a common scenario. The OU isn't a filterable property that can be used in the RecipientFilter parameter of an e-mail address policy or an address list. Note: Dynamic distribution groups have an additional parameter that you can use to restrict it to recipients in a particular OU or container.

If the recipients in that OU don't share any common properties that you can filter by, such as department or location, you can populate one of the custom attributes with a common value, as shown in this example.

Get-Mailbox -OrganizationalUnit Sales | Set-Mailbox CustomAttribute1 "SalesOU"

Now you can create an e-mail address policy for all recipients that have the CustomAttribute1 property that equals SalesOU, as shown in this example.

New-EmailAddressPolicy -Name "Sales" -RecipientFilter { CustomAttribute1 -eq "SalesOU"} -EnabledEmailAddressTemplates "SMTP:%s%2g@sales.contoso.com"

Return to top

Custom Attribute Example with the ConditionalCustomAttributes Parameter

When creating dynamic distribution groups, e-mail address policies, or address lists, you don't need to use the RecipeintFilter parameter to specify custom attributes. You can use the ConditionalCustomAttribute1 to ConditionalCustomAttribute15 parameters instead. You can create a dynamic distribution group based on the recipients whose CustomAttribute1 is set to SalesOU, as shown in this example.

New-DynamicDistributionGroup -Name "Sales Users and Contacts" -IncludedRecipients "MailboxUsers,MailContacts" -ConditionalCustomAttribute1 "SalesOU"

Note: You must use the IncludedRecipients parameter if you use a Conditional parameter. In addition, you can't use Conditional parameters if you use the RecipientFilter parameter. If you want to include additional filters to create your dynamic distribution group, e-mail address policies, or address lists, you should use the RecipientFilter parameter. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Disconnected Mailboxes

Exchange 2010 [This topic is in progress.] Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 Each mailbox consists of an Active Directory user and the mailbox data stored in the Exchange mailbox database. (The following figure shows the components of a mailbox.) All configuration data for a mailbox is stored in the Exchange attributes of the Active Directory user object. The mailbox database contains the mail data that's in the mailbox associated with the user account.

A disconnected mailbox is a mailbox object in the mailbox database that isn't associated with an Active Directory user account. There are two types of disconnected mailboxes:

Disabled mailboxes When a mailbox is disconnected or removed by using the Disable-Mailbox or Remove-Mailbox cmdlet, Exchange retains the deleted mailbox and the mailbox is switched to a disabled state. With disabled mailboxes, you can recover mailbox data without having to restore the entire mailbox database. Disabled mailboxes are retained in the mailbox database until the deleted mailbox retention period expires or until the mailbox is permanently deleted. Soft-deleted mailboxes When mailboxes are moved from a Microsoft Exchange Server 2010 Service Pack 1 (SP1) database to any other database, Exchange doesn't fully delete the mailbox from the source database upon completion of the move. Instead, the mailbox in the source mailbox database is switched to a softdeleted state. With soft-deleted mailboxes, you can use the MailboxRestoreRequest cmdlet set to access mailbox data during a mailbox restore operation. Softdeleted mailboxes are retained in the source database until either the deleted mailbox retention period expires or until the Remove-StoreMailbox cmdlet is used to purge the mailbox. For more information, see Restore a Soft-Deleted Mailbox. For more information and detailed steps about how to manage disconnected mailboxes, see Managing Disconnected Mailboxes.

Working with Disabled Mailboxes

There are three operations you can perform on a disabled mailbox:

Connect it to an existing user account in Active Directory Restore it to a new or existing user account in Active Directory Permanently delete it from the Exchange mailbox database During the time a disabled mailbox is retained in the Exchange mailbox database, you can connect it to an existing Active Directory user account that isn't associated with another mailbox. Scenarios in which you may want to connect or restore a disabled mailbox include the following:

You disabled a mailbox and now want to reconnect the mailbox to an Active Directory user account. You removed a mailbox by using the Remove-Mailbox cmdlet without the Permanent or StoreMailboxIdentity parameters and now want to reconnect the mailbox to a different Active Directory user account. You want to convert a user mailbox to a linked mailbox associated with a user account external to the forest in which your Exchange organization exists. The resource forest scenario is an example of when you would want to associate a mailbox with an external account. In a resource forest scenario, user objects in the Exchange forest have mailboxes, but the user objects are disabled for logon. You must associate these mailbox objects in the Exchange forest with enabled user objects in the external accounts forest.

Connecting or Restoring Disabled Mailboxes

In Exchange 2010 SP1, there are two methods by which you can reconnect a disabled mailbox. In the first method, you can still use the Connect-Mailbox cmdlet in the Exchange Management Shell or the Connect Mailbox wizard in the Exchange Management Console (EMC) to connect a disabled mailbox. This method was introduced in Exchange 2007. The Connect Mailbox wizard is available from the action pane when you select the Disconnected Mailbox node under Recipient Configuration. The second method to reconnect a disabled mailbox uses the MailboxRestoreRequest cmdlet set in the Shell. This cmdlet set uses the Mailbox Replication Service MRS to reconnect the mailbox. You cant use the EMC to perform this process. After you reconnect a mailbox to an existing Active Directory user account, that user account becomes the owner of the mailbox and has full access to any content within the mailbox. For detailed instructions about how to connect disabled mailboxes, see Connect or Restore a Disabled Mailbox

Permanently Deleting a Disabled Mailbox

As stated previously, Exchange retains disabled mailboxes in the mailbox database based on the deleted mailbox retention settings configured for that mailbox database. After the specified retention period, a disabled mailbox is permanently deleted from the Exchange mailbox database. However, you can also permanently

delete a disabled mailbox at any time by using one of the following two methods:

You can use the Remove-Mailbox cmdlet in the Shell. To do this, you need to set the Permanent parameter to $true when you run the command. If you want to permanently delete the data within the mailbox database for a previously disabled mailbox, you must use the StoreMailboxIdentity parameter with the Remove-Mailbox cmdlet. You can use the Get-MailboxStatistics cmdlet to determine the value you need to supply to the StoreMailboxIdentity parameter for a disconnected mailbox. For an example of this scenario, see the third code example in the reference topic Remove-Mailbox. You can use the Remove-StoreMailbox cmdlet to purge a mailbox and all of its message content from the mailbox database. This results in permanent data loss for the mailbox being purged. You can only run this cmdlet against disconnected mailboxes. For more information, see Permanently Delete a Disconnected Mailbox.

Working with Soft-Deleted Mailboxes

A soft-deleted mailbox is created when the mailbox is moved from one Exchange Server 2010 SP1 mailbox database to any other mailbox database. Exchange doesnt fully delete the mailbox from the source database after a move in case an error occurs causing the mailbox on the destination database to fail. You can always restore the source mailbox and try again. Exchange will retain the soft-deleted mailbox for the retention period. There are two operations that you can perform on soft-deleted mailboxes:

1. You can restore the soft-deleted mailbox to an existing active directory user. 2. You can permanently delete the soft-deleted mailbox.

Restoring a Soft-Deleted Mailbox

Permanently Deleting a Soft-Deleted Mailbox

Working with Disconnected Personal Archives

Personal archives become disconnected when they are disabled. Similar to disabled mailboxes, a disconnected personal archive can be connected by using the Connect-Mailbox cmdlet with the Archive parameter. The primary mailbox and the personal archive share the same legacy distinguished name (DN), so you must connect the personal archive to the same user mailbox that it was previously connected to. You can't connect the personal archive to a different user mailbox. There are two operations that you can perform on disconnected personal archives:

Connect it to an existing mailbox in Active Directory Permanently delete it from the Exchange mailbox database

Connecting Disconnected Personal Archives

A disconnected personal archive is retained in the mailbox database for a specified amount of time. By default, Exchange retains the disconnected personal archives for 30 days. During this time, you can recover the personal archive by associating it with an existing mailbox. Note: If you disable a personal archive for a user mailbox and then enable a personal archive for that same user, that user mailbox will get a new personal archive. You must use the Connect-Mailbox cmdlet to connect a disabled personal archive to an existing mailbox. For more information, see Connect a Disconnected Personal (On-Premises) or Cloud-Based Archive.

Permanently Deleting a Disabled Personal Archive

Exchange retains disconnected personal archives based on the deleted mailbox retention settings configured for the mailbox database. The default retention period is 30 days. After the specified retention period, a disconnected personal archive is permanently deleted from the mailbox database. You can also permanently delete a disconnected mailbox at any time by using the Remove-Mailbox cmdlet with the Archive switch in the Shell. To do this, you need to set the Permanent parameter to $true when you run the command.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding the Microsoft Exchange Recipient

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-01-27 This topic describes the configuration and management of the Microsoft Exchange recipient. The Microsoft Exchange recipient is a special Microsoft Exchange Server 2010 recipient object that provides a unified and well-known message sender that differentiates system-generated messages from other messages. The Microsoft Exchange recipient is functionally equivalent to an internal postmaster. The Microsoft Exchange recipient replaces the System Administrator sender that was used for systemgenerated messages in earlier versions of Exchange. Messages from the Microsoft Exchange recipient display Microsoft Exchange as the sender. The types of messages sent by the Microsoft Exchange recipient include:

DSN messages Journal reports Quota messages Agent-generated messages Contents Configuring the Microsoft Exchange Recipient Internal and External Delivery of System Messages Microsoft Exchange Recipient in Cross-Forest Scenarios

Configuring the Microsoft Exchange Recipient

Unlike a mailbox, mail user, or mail contact, the Microsoft Exchange recipient isn't a typical recipient object. The Microsoft Exchange recipient isn't managed by using the typical recipient tools found in the Exchange Management Console (EMC) or the Exchange Management Shell. However, you can use the Set-OrganizationConfig cmdlet in the Shell to perform the following configuration tasks:

Allow or prevent the application of the default e-mail address policy to the Microsoft Exchange recipient. By default, the default mail address policy is applied to the Microsoft Exchange recipient. Configure a recipient object to receive messages that are sent to the Microsoft Exchange recipient. By default, no recipient is configured to receive messages that are sent to the Microsoft Exchange recipient. Configure the e-mail addresses of the Microsoft Exchange recipient. This includes specifying a primary SMTP address.

Microsoft Exchange Recipient Parameters

The following table describes the Set-OrganizationConfig parameters used to configure the Microsoft Exchange recipient.

Microsoft Exchange recipient parameters in Set-OrganizationConfig

Parameter MicrosoftExchangeRecipientEmailAddresses Default value MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e@<Accepted Domain>. The <Accepted Domain> placeholder represents an accepted domain that's used in an e-mail address policy. For every accepted domain that's used in an e-mail address policy, there's a corresponding e-mail address. Description

The MicrosoftExchangeRecipientEmailAddresses one or more e-mail addresses for the Microsoft Exc All valid Exchange 2010 e-mail address types may b specify multiple values for this parameter as a comm If the MicrosoftExchangeRecipientEmailAddressPolicyEn is set to $true, the e-mail addresses are automatic

the default e-mail address policy, and you can't use MicrosoftExchangeRecipientEmailAddresses E-mail addresses that you specify by using the MicrosoftExchangeRecipientEmailAddresses existing e-mail addresses that are already configure MicrosoftExchangeRecipientEmailAddressPolicyEnabled $true

The MicrosoftExchangeRecipientEmailAddressPolicyEna specifies whether the default e-mail address policy is applied to the Microsoft Exchange recipient. The def $true. If this parameter is set to $true

automatically adds new e-mail addresses to the Mic recipient when e-mail address policies are added or Exchange organization. If this parameter is set to

manually add new e-mail addresses to the Microsof recipient when e-mail address policies are added or If you change the value of the MicrosoftExchangeRecipientEmailAddressPolicyEnabled $false to $true, any e-mail addresses that you de

the MicrosoftExchangeRecipientEmailAddresses preserved. However, the value of the MicrosoftExchangeRecipientPrimarySmtpAddress param MicrosoftExchange329e71ec88ae4615bbc36ab6ce41 Domain in Highest Priority E-mail Address Policy MicrosoftExchangeRecipientPrimarySmtpAddress MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e@<Accepted The MicrosoftExchangeRecipientPrimarySmtpAddress

Domain in Highest Priority E-mail Address Policy>

specifies the primary return SMTP e-mail address fo Exchange recipient. If the MicrosoftExchangeRecipientEmailAddressPolicyEnabled to $true, you can't use the

MicrosoftExchangeRecipientPrimarySmtpAddress If you modify the value of the MicrosoftExchangeRecipientPrimarySmtpAddress automatically added to the list of e-mail addresses t in the MicrosoftExchangeRecipientEmailAddresses The MicrosoftExchangeRecipientPrimarySmtpAddress meaningful only if the Microsoft Exchange recipient one defined SMTP e-mail address. If the MicrosoftExchangeRecipientEmailAddresses defined SMTP e-mail address, the value of the MicrosoftExchangeRecipientPrimarySmtpAddress MicrosoftExchangeRecipientEmailAddresses MicrosoftExchangeRecipientReplyRecipient $null

The MicrosoftExchangeRecipientReplyRecipient recipient that should receive messages that are sent Exchange recipient. Typically, you would configure a receive the messages that are sent to the Microsoft recipient. This parameter can take any of the followin specified recipient: Distinguished name (DN) Canonical name GUID Name Display name Alias Exchange DN Primary SMTP e-mail address

If you don't configure a recipient for the Microsoft E recipient, messages that are sent to the Microsoft Ex are discarded.

Internal and External Delivery of System Messages

The Microsoft Exchange recipient is used as the sender for system-generated messages sent to internal message senders. An internal sender is a recipient object that exists inside the Exchange organization. Specifically, the domain part of the primary SMTP e-mail address of the recipient object must be defined in the list of accepted domains for the Exchange organization. When system-generated messages are sent to an external sender, the Microsoft Exchange recipient isn't used as the sender of the message. Instead, the e-mail address that's specified by the ExternalPostmasterAddress parameter in the Set-TransportConfig cmdlet is used. For more information, see Configure the External Postmaster Address. However, under certain circumstances, the Microsoft Exchange recipient could be exposed to external recipients. These circumstances include but aren't limited to the following:

Alternative recipients Externally forwarded meeting requests External out-of-office notifications Journal reports

Microsoft Exchange Recipient in Cross-Forest Scenarios

There's only one Microsoft Exchange recipient in an Exchange organization. Exchange 2010 determines that a message is sent from the Microsoft Exchange recipient by comparing the e-mail address of the message sender to the list of e-mail addresses that are defined by the MicrosoftExchangeRecipientEmailAddresses parameter. If Exchange 2010 determines that the sender is the Microsoft Exchange recipient, any messages from the sender are exempt from any configured message size limits that may exist in the Exchange organization. However, in a cross-forest scenario, each forest has its own Microsoft Exchange recipient and its own message size limits. When messages are sent from the Microsoft Exchange recipient in the source forest, the target forest treats the sender as it would any other unauthenticated, external recipient. Even though the message is a system-generated message from the source forest, the message is still subject to any message size limits that are configured in the target forest. To make sure that each forest can recognize messages that are sent from the Microsoft Exchange recipient in the other forest, you can configure the Microsoft Exchange recipient in each forest with an additional e-mail address that matches the primary e-mail address of the Microsoft Exchange recipient in the other forest. With this configuration, each forest can recognize messages that are sent from the Microsoft Exchange recipient in the other forest. This configuration correctly exempts messages that are sent from the Microsoft Exchange recipient in both forests from any message size limits. However, this configuration introduces issues if either forest allows messages to be sent to the Microsoft Exchange recipient by using the MicrosoftExchangeRecipientReplyRecipient parameter. Because the Microsoft Exchange recipient in each forest is configured by using the e-mail addresses of the Microsoft Exchange recipients of both forests, any messages that are sent to the Microsoft Exchange recipient will never leave the local forest from which the messages are sent. The messages will be sent to the recipient that's specified by the MicrosoftExchangeRecipientReplyRecipient parameter in the local forest. If one administrator is responsible for the messaging administration of both forests, that administrator can read the messages that are sent to the Microsoft Exchange recipient in both forests. However, if different administrators are responsible for each forest, the administrator of one forest can't manage the messages that are incorrectly sent to the Microsoft Exchange recipient in the other forest. For more information about how to administer Exchange 2010 in cross-forest scenarios, see "Understanding Multiple Forest Administration" in Deploy Multiple Forest

Topologies.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Recipient Restrictions

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-02-01 You can configure restrictions on the recipients in your organization. These restrictions allow you to use recipients consistent with your organization's policies. Looking for management tasks related to managing Mailbox servers? See Managing Mailbox Servers. Contents Message Size Restrictions Message Delivery Restrictions Maximum Recipients per Message Restrictions Mailbox Size Restrictions Public Folder Size Restrictions

Message Size Restrictions

Restrictions on the size of a message are the most commonly used restrictions in any messaging system. Setting a maximum message size prevents your messaging system, or the underlying network infrastructure, from being overwhelmed. Depending on what you want to do, you can configure message size restrictions for several components. For example, you can restrict the total size of a message or the size of the individual message components (such as the message header, attachments, or the number of recipients). Although you can also specify whether message size restrictions are applied to your entire Microsoft Exchange Server 2010 organization or to a specific connector or user object, this section focuses only on message size restrictions that you can apply to recipients. For a complete list of message size restrictions that you can configure in an Exchange 2010 organization, see Understanding Message Size Limits. When configuring message size restrictions for individual recipients, it's important to consider other message size restrictions that may exist in your organization. For example, assume that the Hub Transport servers in your organization are configured to restrict message size to 10 megabytes (MB). In this case, for a mail contact that has external addresses, you should set the maximum receive size to be no larger than 10 MB. Although a sender in your organization will be able to submit a message larger than 10 MB to this mail contact, the message would be rejected by the Hub Transport server. To learn more about how different message size restrictions affect each other and the order of precedence, see Understanding Message Size Limits.

Message Size Restrictions for All Recipient Types

Exchange 2010 can deliver or route messages to all recipients. Therefore, you can set a maximum receiving message size limit for any recipient type in your Exchange organization. If a sender attempts to send a message that's larger than the specified size, the message is returned to the sender with a descriptive error message. In the Exchange Management Console (EMC), you set the maximum receiving message size by using the Mail Flow Settings tab of the recipient's properties. In the Exchange Management Shell, use the MaxReceiveSize parameter of the appropriate Set- cmdlet. For an example about how to configure receiving message size restrictions for a recipient, see Configure Message Size Limits for a Mailbox or a Mail-Enabled Public Folder.

Message Size Restrictions Specific to Mailboxes and Mail-Enabled Public Folders

Mailboxes and mail-enabled public folders are the only recipient types that can submit messages to your Exchange messaging system. Therefore, in addition to setting receiving message size restrictions, you can also set sending message size restrictions. In the EMC, you set the maximum sending message size of a mailbox by using the Mail Flow Settings tab of the mailbox properties. In the Shell, use the MaxSendSize parameter of the Set-Mailbox and Set-MailPublicFolder cmdlets. For an example about how to configure sending message size restrictions for mailboxes and mailenabled public folders, see Configure Message Size Limits for a Mailbox or a Mail-Enabled Public Folder. Important: If you implement sending message size restrictions for your mailbox users, you should also make sure that your Client Access servers are configured to accept client requests that are equal to or larger than the sending message size limit that you configured. Microsoft Office Outlook Web App uses ASP.NET and is thereby affected by the ASP.NET configuration. ASP.NET has a setting, maxRequestLength, which determines the maximum amount of data that the Web browser can submit to the Client Access server. If this limit is lower than the sending message size restriction, your users may receive a confusing error. To learn more about managing the maximum message size in Outlook Web App, see Configure Maximum Message Size in Outlook Web App.

Public Folder Management Console

The Public Folder Management Console is a Microsoft Management Console (MMC) 3.0-based interface that provides Exchange administrators with a graphical user interface (GUI) to create, configure, and manage public folders. You can also configure message size restrictions for a mail-enabled public folder by using the Message Size Restrictions option on the Mail Flow Settings tab of the public folder properties in the Public Folder Management Console. To learn more about the

Public Folder Management Console, see Using the Public Folder Management Console. Return to top

Message Delivery Restrictions

With Exchange 2010, you can place restrictions on how messages are delivered to individual recipients. Message delivery restrictions apply to all recipient types and can be useful for controlling access to specific recipients in your Exchange 2010 organization. For example, several organizations specify that only a small set of users can send messages to large distribution groups. You can configure the following message delivery restrictions for a recipient:

Accept messages from a specific list of senders If you specify a list of senders from which to accept messages, the recipient will receive messages only from those senders. By default, all recipients are configured to accept messages from all senders. Use this restriction for recipients for which you want only a small number of authorized senders to be able to send messages. For example, you may want to configure a distribution group that contains all the employees in your organization to accept messages from only specific employees in the Human Resources department who are responsible for company-wide communications. Another scenario where you can use this restriction is for mail contacts that represent suppliers for a retail organization. You may want to configure each of these mail contacts to accept messages from only the buyers who work directly with those suppliers. Reject messages from a specific list of senders If you specify a list of senders from which to reject messages, the recipient will reject messages from those senders. By default, all recipients are configured not to reject messages from any senders. Note: This restriction overrides the Accept messages from a specific list of senders restriction. If a sender is listed in both lists, any messages sent by that sender will be rejected. Use this restriction to block specific users from sending messages to specific recipients. For an example about how this restriction is useful, consider the following scenario. You create a distribution group called All Employees. You configure that distribution group to accept messages from only those senders that are a member of the Human Resources distribution group. However, the Human Resources distribution group also includes mailboxes for interns whom you don't want to allow access to the All Employees distribution group. Therefore, to prevent the intern mailboxes from sending messages to the All Employees distribution group, you can specify the intern mailboxes when configuring the Reject messages from a specific list of senders restriction for the All Employees group. Require that all senders are authenticated If you configure a recipient to require that all senders are authenticated, any messages from senders that don't have valid logon credentials in your organization will be rejected. By default, only new distribution groups and dynamic distribution groups are configured to require all senders to be authenticated. Note: In previous versions of Exchange, by default, no recipients were configured to require all senders to be authenticated. Therefore, any distribution groups that you migrate from a previous version of Exchange won't have this restriction configured. Use this restriction to specify that recipients receive messages only from internal senders that have been successfully authenticated. For example, to prevent messages that originate outside of your Exchange organization from being delivered to distribution groups that are used for internal communications, you can configure these groups to require sender authentication. For details about how to configure message delivery restrictions for a recipient, see Configure Message Delivery Restrictions. Return to top

Maximum Recipients per Message Restrictions

It can take a significant amount of time for a Hub Transport server to route messages that are addressed to a large number of recipients. As a result, this may affect the performance of the Hub Transport server, which could impact the overall message delivery in your Exchange organization. To eliminate this risk, you can restrict the number of recipients that are allowed per message. Although you can configure this restriction at the mailbox level, you can also configure it at a higher level, such as the organization level, connector level (only for Receive connectors), and Hub Transport server level. Generally, it's a best practice to configure this setting at a higher level and use the mailbox-level configuration only for exceptions. For more information about the different levels at which you can configure this restriction, as well as a list of default values, see Understanding Message Size Limits. For details about how to configure maximum recipients per message restrictions for a mailbox, see Restrict the Number of Recipients per Message. Return to top

Mailbox Size Restrictions

You can configure storage quotas for mailboxes. By using storage quotas, you can control the size of mailboxes and manage the growth of mailbox databases. For detailed steps about how to configure storage quotas for a mailbox, see Configure Storage Quotas for a Mailbox. Note: You can also configure storage quotas at the mailbox database level. The quotas that you configure for a mailbox database apply to all mailboxes in that database, unless the mailbox is configured not to use mailbox database defaults. Generally, it's a best practice to configure storage quotas at the mailbox database level and use the mailbox level configuration only for exceptions. For detailed steps about how to configure storage quotas for a mailbox database, see Configure Mailbox Database Properties. Because storage quotas have a direct impact on your storage capacity planning, you must plan your storage quotas carefully. Storage quotas, number of mailboxes per mailbox database, and the storage subsystem that hosts each mailbox database are all factors that you should consider when planning your deployment. Before deploying Unified Messaging (UM) in your Exchange organization, you must review any existing storage quotas you've configured. Because Windows Media Audio (WMA) and waveform audio (.wav) files are attached to each voice message, voice messages may be larger than e-mail messages. As a result, voice messages

may cause user mailboxes to exceed their quota more quickly than e-mail messages that don't include attachments. To learn more about the impact of Unified Messaging on storage quotas, see Understanding Storage Quotas and Voice Mail. Return to top

Public Folder Size Restrictions

Similar to mailboxes, you can configure storage quotas for your mail-enabled public folders. By using storage quotas, you can control the size of mail-enabled public folders and manage the growth of public folder databases. In addition to storage quotas, you can also define age limits for your public folders. If you specify an age limit for a public folder, any items in that public folder that exceed the age limit without having been modified are removed automatically from that public folder. This provides administrators with an additional option for controlling the growth of their public folder databases. For detailed steps about how to configure storage quotas and age limits for public folders, see Configure Public Folder Properties. Note: Storage quotas and age limits also apply to public folders that aren't mail-enabled. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Recipient Scope

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-01-20 You manage recipients by using the Exchange Management Console (EMC) and the Exchange Management Shell. These management interfaces provide the flexibility to view and manage recipients that are stored at various levels of an Active Directory hierarchy. Microsoft Exchange Server 2010 management interfaces do this by using a concept called the recipient scope. Recipient scope refers to the specified portion of the Active Directory hierarchy that the EMC and the Shell will use for recipient management. When you set the recipient scope to a specific location within Active Directory, you can view and manage all recipients stored in that location and all the containers under it. For example, if you set the recipient scope to a domain, the Exchange management interface you're using lets you view and manage all recipients that are stored in all organizational units (OUs) within that domain. Note: The recipient scope is simply a view of Active Directory and has no security context. You can access and manage only the objects and containers to which your user account has been granted permission, regardless of the recipient scope setting. Setting the recipient scope does more than limit the number of recipients returned. When you set the recipient scope, the management interface you are using operates within the recipient scope that you specified. When performing recipient management tasks, the management interface can view only the portion of Active Directory that you set as the recipient scope. For example, assume that your company has the Active Directory structure shown in the following figure. If you set the recipient scope to the Field OU of the corp.contoso.com domain, the Exchange management interface can view only the portion of Active Directory that's highlighted in the following figure.

The recipient scope applies to the first class recipient objects. First class recipient objects refer to all mailboxes, mail contacts, mail users, distribution groups, and dynamic distribution groups. Important: The properties of first class recipient objects aren't bound by the recipient scope. For example, when adding members to a distribution group, you can select any recipient in the forest, regardless of the recipient scope. Similarly, when configuring the manager of a mailbox user, you can select any mail-enabled user or contact in the forest. Looking for management tasks related to managing Mailbox servers? See Managing Mailbox Servers.

Recommendations for Working with Recipient Scope

The following are some recommendations for working with recipient scope:

In large organizations, recipients may be spread across multiple domains or OUs. In these cases, setting a recipient scope that focuses on the specific set of recipients you're managing may reduce the number of recipients that are returned, thereby improving the performance of the Exchange management interfaces. Set the recipient scope to the entire forest only when performing specific tasks that apply to all recipients in the forest. When the recipient scope is set to the entire forest, the management interfaces use a global catalog server to access Active Directory. The recipient information that's displayed in the interfaces is dependent on the replication latencies of Active Directory. As a result, the information that's displayed may not be entirely up to date. Likewise, any updates made through the interfaces may not take effect until Active Directory replicates the changes. Furthermore, if you have a large Active Directory deployment with recipients spread across multiple domains, using a forest-wide recipient scope can reduce the performance of the management interfaces due to the sheer number of recipients returned. If you have a complex Active Directory replication topology, or if you have high replication latency, specify the global catalog that's most up to date when setting the recipient scope to the entire forest. If you use a specific domain controller on which all updates to Active Directory are made, you can specify that domain controller as the preferred recipient domain controller when setting the recipient scope. For example, if you have an account provisioning system that works with a specific domain controller, you can specify that domain controller as the preferred recipient domain controller.

Setting the Recipient Scope

Exchange 2010 management interfaces always start with the recipient scope at the domain level. The default setting for the recipient scope is always set to the domain of the computer that's running the management interface. Neither the user account that's being used nor the Exchange servers being managed has bearing on the default value of the recipient scope. To illustrate this point, consider a scenario where the organization contoso.com has an Active Directory forest with three domains: contoso.com (which contains all computer accounts), users.contoso.com (which contains all user accounts), and exchange.contoso.com (which contains the Exchange servers). To administer an Exchange server in exchange.contoso.com, an administrator logs on to a computer in contoso.com with a user account in users.contoso.com. When the administrator opens the

EMC or the Shell, by default, the recipient scope is set to contoso.com. Depending on the task you need to accomplish, you can change the recipient scope to a different location in Active Directory. You can set the recipient scope to a single OU, to the top level of an OU hierarchy, to a domain, or even to the entire forest.

Recipient Scope in the EMC

Changing the recipient scope in the EMC changes the set of recipients that are displayed in the result pane of the Recipient Configuration node. The dialog boxes that you use to select recipients or OUs (located on various wizard pages) also work within the same scope. For example, if you're mail-enabling an existing contact, the Select Contact dialog box in the New Mail Contact wizard displays only the contacts within the recipient scope that aren't already mail-enabled. Note: The Microsoft Management Console (MMC) saves any changes you make to a snap-in as preferences in your user profile on the administrator computer. The recipient scope setting is also saved as one of your preferences. As a result, the next time you start the EMC on the same computer, the default setting of the recipient scope is overwritten by the scope last specified. However, if you use another computer or a different user account to run the EMC, you will need to adjust the recipient scope again. To modify the recipient scope in the EMC, select the Recipient Configuration node, and then click Modify Recipient Scope in the action pane. For more information about changing the recipient scope in the EMC, see Change the Recipient Scope.

Recipient Scope in the Shell

Because you must manually type all values in the Shell, it's important that you keep the recipient scope in mind as you manage recipients. If you make references to objects that are outside the recipient scope, you may receive errors. For example, if you try to create a new distribution group in an OU that isn't within the recipient scope you specified, you will receive the error, "Organizational unit <OU name> wasn't found. Please make sure you have typed it correctly". You can view or modify the recipient scope by using the Set-AdServerSettings cmdlet. When you change the recipient scope in the Shell, you change the set of recipients that are returned for the Get- cmdlets of the recipient. The recipient scope is accessible by using the Set-AdServerSettings cmdlet. Note: The default scope isn't retained when you close the Shell. The Shell resets to the default domain-level recipient scope the next time that the Shell is opened.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Understanding Recoverable Items

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-02-14 To protect from accidental or malicious deletion and to facilitate discovery efforts commonly undertaken before or during litigation or investigations, Microsoft Exchange Server 2010 introduces the Recoverable Items folder. The Recoverable Items folder replaces the feature known as the dumpster in Exchange Server 2007. The Recoverable Items folder is used by the following Exchange features:

Deleted item retention Single item recovery Litigation hold Mailbox audit logging Contents Terminology Recoverable Items Folder Recoverable Items Mailbox Quotas

Terminology
Knowledge of the following terms will help you understand the content in this topic.

Delete Describes when an item is deleted from any folder and placed in the Deleted Items default folder.

Soft delete Describes when an item is deleted from the Deleted Items default folder and placed in the Recoverable Items folder. Additionally describes when a Microsoft Outlook user deletes an item by pressing Shift+Delete, which bypasses the Deleted Items folder and places the item directly in the Recoverable Items folder.

Hard delete Describes when an item is marked to be purged from the mailbox database. This is also known as a store hard delete.

Return to top

Recoverable Items Folder

To better meet customers' legal compliance requirements, the dumpster is reinvented as the Recoverable Items folder in Exchange 2010. The Recoverable Items folder resides in the non-IPM subtree of each mailbox. The non-IPM subtree is a storage area within the mailbox that contains operational data about the mailbox. This subtree isn't visible to users using Outlook, Microsoft Office Outlook Web App, or other e-mail clients. This architectural change provides the following key benefits:

When a mailbox is moved to another mailbox database, the Recoverable Items folder moves with it. The Recoverable Items folder is indexed by Exchange Search and can be discovered using Multi-Mailbox Search. The Recoverable Items folder has its own storage quota. Exchange can prevent data from being purged from the Recoverable Items folder. Exchange can track edits of certain content. The Recoverable Items folder contains the following subfolders:

Deletions This subfolder contains all items deleted from the Deleted Items folder. (In Outlook, you can soft delete an item by pressing Shift+Delete.) This subfolder is exposed to users through the Recover Deleted Items feature in Outlook and Outlook Web App. Versions If either litigation hold or single item recovery is enabled, this subfolder contains the original and modified copies of the deleted items. This folder isn't visible to end users. Purges If either litigation hold or single item recovery is enabled, this subfolder contains all items that are hard deleted. This folder isn't visible to end users. Audits If mailbox audit logging is enabled for a mailbox, this subfolder contains the audit log entries. To learn more about mailbox audit logging, see Understanding Mailbox Audit Logging.

Deleted Item Retention

An item is considered to be soft deleted in the following cases:

A user deletes an item or empties all items from the Deleted Items folder. A user presses Shift+Delete to delete an item from any other mailbox folder. Soft-deleted items are moved to the Deletions subfolder of the Recoverable Items folder. This provides an additional layer of protection so users can recover deleted items without requiring Help desk intervention. Users can use the Recover Deleted Items feature in Outlook or Outlook Web App to recover a deleted item. Users can also use this feature to permanently delete an item.

Items remain in the Deletions subfolder until the deleted item retention period is reached. The default deleted item retention period for a mailbox database is 14 days. You can modify this period for a mailbox database or for a specific mailbox. In addition to a deleted item retention period, the Recoverable Items folder is also subject to quotas. To learn more, see Recoverable Items Mailbox Quotas later in this topic. After the deleted item retention period elapses, the item is moved to the Purges folder and is no longer visible to the user. When the Managed Folder Assistant processes the mailbox, items in the Purges subfolder are purged from the mailbox database.

Single Item Recovery

If an item is removed from the Deletions subfolder, either using the Recover Deleted Items feature or by an automated process such as the Managed Folder Assistant, the item can't be recovered by the user. In previous versions of Exchange, recovering these items required the administrator to restore the mailbox database or a mailbox from backup copies. This process generally delayed recovery by minutes or hours, depending on the backup mechanism used. Exchange 2010 introduces single item recovery, a feature you can use to recover items without having to restore the mailbox databases using backup media. This results in considerably shorter recovery periods. When the Managed Folder Assistant processes the Recoverable Items folder for a mailbox that has single item recovery enabled, any item in the Purges subfolder isn't purged if the deleted item retention period hasn't elapsed for that item. Additionally, if the user changes certain properties of an item in any mailbox folder, a copy of the item is made before the modification is written to the Exchange store. The copy is stored in the Versions subfolder by a process known as copy-on-write page protection. You can recover different versions of a modified item until the deleted item retention period elapses. The following table lists the contents of and actions that can be performed in the Recoverable Items folder if single item recovery is enabled.

Recoverable Items folder and single item recovery

State of single item recovery Enabled Recoverable Items folder contains softdeleted items Yes Recoverable Items folder contains modified and harddeleted items Yes Users can purge items from the Recoverable Items folder No Managed Folder Assistant automatically purges items from the Recoverable Items folder

Yes. By default, all items are purged after 14 days, with the exception of calendar items, which are purged after 120 days. Yes. By default, all items are purged after 14 days, with the exception of calendar items, which are purged after 120 days. If the Recoverable Items warning quota is reached before the deleted item retention period elapses, messages are deleted in first in, first out (FIFO) order.

Disabled

Yes

No

Yes

Single item recovery isn't enabled by default for new mailboxes or mailboxes moved from a previous version of Exchange. You must use the Exchange Management Shell to enable single item recovery for a mailbox, and then configure or modify the deleted item retention period. To learn more about how to enable single item recovery for a mailbox and to perform single item recovery of deleted items, see the following topics:

Enable Single Item Recovery for a Mailbox Perform Single Item Recovery

Litigation Hold
Exchange 2010 introduces Multi-Mailbox Search, a feature that administrators or records managers can use with delegated Discovery Management permissions to perform discovery searches of mailbox content. Exchange 2010 also introduces litigation hold, which you can use to preserve items in user mailboxes and protect the items from deletion by users or automated processes. Placing a mailbox on litigation hold stops the Managed Folder Assistant from automatically purging messages from the Purges subfolder. Additionally, copy-on-write page protection is also enabled for the mailbox. Copy-on-write page protection creates a copy of the original item before any modifications are written to the Exchange store. After the mailbox is removed from litigation hold, the Managed Folder Assistant resumes automated purging. The following table lists the contents of and actions that can be performed in the Recoverable Items folder if litigation hold is enabled.

Recoverable Items folder and litigation hold

State of litigation hold Enabled Disabled Recoverable Items folder contains soft-deleted items Yes Yes Recoverable Items folder contains modified and harddeleted items Yes No Users can purge items from the Recoverable Items folder No Yes Managed Folder Assistant automatically purges items from the Recoverable Items folder No Yes

To learn more about Multi-Mailbox Search and litigation hold, see the following topics:

Understanding Multi-Mailbox Search Understanding Litigation Hold

Copy-on-Write Page Protection and Modified Items

If a user who is placed on litigation hold (or has single item recovery enabled) modifies specific properties of a mailbox item, a copy of the original mailbox item is created before the changed item is written. The original copy is saved in the Versions subfolder. This process is known as copy-on-write page protection. Copy-onwrite page protection applies to items residing in any mailbox folder. The Versions subfolder isn't visible to users.

The following table lists the message properties that trigger copy-on-write page protection.

Properties that trigger copy-on-write page protection

Item type Messages (IPM.Note*) Posts (IPM.Post*) Properties that trigger copy-on-write page protection

Subject Body Attachments Senders and recipients Sent and received dates

Items other than messages and posts

Any change to a visible property, except the following: Item location (when an item is moved between folders) Item status change (read or unread) Changes to a retention tag applied to an item

Items in the Drafts default folder Important:

None. Items in the Drafts folder are exempt from copy-on-write page protection.

In Exchange 2010 Service Pack 1 (SP1), copy-on-write page protection doesn't save a version of the meeting when a meeting organizer receives responses from attendees and the meeting's tracking information is updated. Also, changes to RSS feeds aren't captured by copy-on-write page protection. When litigation hold is removed from a mailbox and single item recovery is disabled, copies of modified items stored in the Versions folder are removed. Return to top

Recoverable Items Mailbox Quotas

When an item is moved to the Recoverable Items folder, its size is deducted from the mailbox quota and added to the size of the Recoverable Items folder. In Exchange 2010, mailbox databases have a configurable Recoverable Items warning quota (soft limit) of 20 gigabytes (GB) and a Recoverable Items quota (hard limit) of 30 GB. By default, these limits are inherited by all mailboxes in the database. However, you can configure individual mailboxes with different quotas. To learn more, see Configure Deleted Item Retention and Recoverable Items Quotas. When the Recoverable Items folder for a mailbox reaches the Recoverable Items quota, no more items can be stored in the folder. This impacts mailbox functionality in the following ways:

Mailbox users can't delete items. The Managed Folder Assistant can't delete items based on retention tag or managed folder settings. For mailboxes that have single item recovery or litigation hold enabled, the copy-on-write page protection process can't maintain versions of items edited by the user. For mailboxes that have mailbox audit logging enabled, no mailbox audit log entries can be saved in the Audits subfolder. For mailboxes that aren't placed on litigation hold, the Managed Folder Assistant automatically purges items from the Recoverable Items folder when the deleted item retention period elapses. If the folder reaches the Recoverable Items warning quota, the assistant automatically purges items in FIFO order. When the Recoverable Items folder reaches the soft and hard limit defaults, you are notified by means of an event log and a Microsoft System Center Operations Manager alert. This alert fires when the Recoverable Items folder first reaches the soft and hard limit defaults, and then once daily afterward. The following table lists the events logged when the Recoverable Items folder reaches the soft and hard limit defaults.

Recoverable Items quota warnings and errors

Event ID 10024 Type Source Message

Warning

MSExchangeIS Mailbox Store

The mailbox for <mailbox user> (GUID) has exceeded the Recoverable Items Warning Quota. Please remove items from Recoverable Items or increase the Recoverable Items Warning Quota and Recoverable Items Quota. If the Recoverable Items Quota is exceeded, the user will be unable to delete items from the mailbox. The mailbox for <mailbox user> (GUID) has exceeded the maximum Recoverable Items Quota. Items cannot be deleted from this mailbox. The mailbox owner should be notified about the condition of the mailbox as soon as possible. Please remove items from Recoverable Items or increase the Recoverable Items Quota to restore functionality. The mailbox:<mailbox user> Recoverable Items size has exceeded the warning quota limit. Items were deleted from Recoverable Items folders to prevent mailbox outage. Recoverable Items Warning Quota: 20 GB (21,474,836,480 bytes) Original Recoverable Items size: 21475005311 Current Recoverable Items size: 21474823820 Folder stats: - Folders processed: RecoverableItemsRoot, RecoverableItemsVersions, RecoverableItemsPurges, RecoverableItemsDeletions - Original folder sizes: 21391661934, 55190914, 1987247, 26157788 (item counts: 276828, 400, 84, 646) - Current folder sizes: 21391480443, 55190914, 1987247, 26157788 (item counts: 276817, 400, 84, 646)

10023

Error

MSExchangeIS Mailbox Store

10023

Warning

MSExchangeMailboxAssistants

If the mailbox is placed on litigation hold, copy-on-write page protection can't maintain versions of modified items. To maintain versions of modified items, you must reduce the size of the Recoverable Items folder. You can use the Search-Mailbox cmdlet to copy messages from the Recoverable Items folder of a mailbox to a discovery mailbox, and then delete the items from the mailbox. Alternatively, you can also raise the Recoverable Items quota for the mailbox. For details, see Clean Up the Recoverable Items Folder.

Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Getting Started With Exchange 2010

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-11-28 Microsoft Exchange Server 2010 Service Pack (SP2) can help you achieve better business outcomes while controlling the costs of deployment, administration, and compliance. Exchange delivers a wide range of deployment options and advanced compliance capabilities. For more information about Exchange 2010, see Exchange 2010 Overview.

Using Exchange 2010 Help

Exchange 2010 SP2 Help content is organized by feature set. Use the top-level nodes to find the most appropriate Help topics when you're planning, deploying, or managing your Exchange 2010 organization. Looking for an offline version of this Exchange 2010 SP2 Help content? Download the Help file from the Microsoft Download Center. Note: Haven't upgraded to Exchange 2010 SP2? You can also download the Help file for previous versions of Exchange. Exchange 2010 SP1 Help Exchange 2010 RTM Help For a discussion of the new features in Exchange 2010 SP2, see What's New in Exchange 2010 SP2. For a detailed roadmap that helps you get acquainted with all the features in Exchange 2010, see Roadmap for Exchange Features.

New to Exchange?
Before deploying Exchange 2010, your existing infrastructure must meet certain prerequisites. To help you plan the deployment of Exchange 2010 into your production environment, read Planning for Exchange 2010.

Upgrading from Exchange 2007?

Before you go too far in your planning for Exchange 2010, make sure your current Exchange Server 2007 organization meets the requirements for upgrading. To learn about planning considerations and configuration steps for upgrading from Exchange 2007 to Exchange 2010, read Exchange 2007 - Planning Roadmap for Upgrade and Coexistence.

Upgrading from Exchange 2003?

You can deploy Exchange 2010 in an existing Exchange Server 2003 organization that's operating in native mode. Coexistence between these two versions is supported. To learn about planning considerations and configuration steps for deploying Exchange 2003 and Exchange 2010 in a coexistence scenario, read Exchange 2003 Planning Roadmap for Upgrade and Coexistence.

Moving to the cloud?

Exchange 2010 SP2 offers organizations the ability to extend the feature-rich experience and administrative control they have with their existing on-premises Exchange 2003, Exchange 2007, or Exchange 2010 organization to the cloud via a hybrid deployment. Hybrid deployments provide the seamless look and feel of a single Exchange organization between an on-premises organization and a cloud-based organization. In addition, hybrid deployments can serve as an intermediate step to moving completely to a cloud-based Exchange organization. For more information, see Hybrid Deployments.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Exchange Server 2010 Documentation Updates

Exchange 2010 Applies to: Exchange Server 2010 SP3 Topic Last Modified: 2013-03-29 In response to the feedback we get from you, our customers, the Exchange Server documentation team is pleased to announce the following additions and changes to our content.

March 2013
Updated Content Add-MailboxPermission Convert Linked Mailboxes Exchange 2010 Deployment Permissions Reference Exchange 2010 Prerequisites Exchange 2010 System Requirements Exchange Server Build Numbers and Release Dates Exchange Server Supportability Matrix New-ActiveSyncMailboxPolicy New-MailboxExportRequest Recover a Deleted Public Folder Recover Public Folders After Accidental Deletion Release Notes for Exchange Server 2010 SP3 Set-ActiveSyncMailboxPolicy Supported Locales for Use with System Messages Understanding Automatic Speech Recognition Directory Lookups Understanding Custom Attributes Understanding Journaling in a Mixed Exchange 2003 and Exchange 2010 Environment Understanding Personal Archives Understanding the Exchange 2010 Store Understanding the Impact of Client Latency on CAS and Mailbox Connections What's New in Exchange 2010 SP3

January 2013
New Content Determine the Exchange Schema Version Issues That Are Fixed in Exchange 2010 SP3 Understanding the Impact of Named Property and Replica Identifier Limits on Exchange Databases Updated Content Account Information Configure the Availability Service for Cross-Forest Topologies Create a Managed Custom Folder Determine the Exchange Schema Version Discontinued Features Exchange Server Supportability Matrix HTTP Connectivity with Autodiscover - Unexpected Exception Implement a Single Sign-On Solution for Live@edu New-WebServicesVirtualDirectory Number of items in retry table has been more than 30000 for 30 minutes Overview of Administrator Audit Logging Release Notes for Exchange Server 2010 SP3 Remote PowerShell connectivity (Internal) failures Start the MRSProxy Service on a Remote Client Access Server The Microsoft Exchange Mailbox Replication service isn't scanning MDB queues for jobs The Test-OutlookConnectivity (Internal) cmdlet failed to run Transport Rule Predicates Understanding Address Book Policies Understanding Proxying and Redirection Understanding the Autodiscover Service What's New in Exchange 2010 SP3 White Papers: Exchange 2010 Tested Solutions

November 2012
New Content Configure a Dedicated Send Connector for a Specific Domain Event IDs 1121 and 5000 Are Logged When You Try to Start the Information Store Service Reclaim Space When the .edb File Size Grows Too Large Updated Content

Add-MailboxPermission Before You Import the Exchange 2010 Monitoring Management Pack Change the Ownership of a Distribution Group Client Language Support for Unified Messaging Configure an Ethical Wall Configure Autodiscover Redirection for the Multi-Tenant Organization Configure Safelist Aggregation Create a Mailbox Export Request Creating a New Monitoring Management Pack for Customizations Discontinued Features Exchange Server 2010 Exchange Server Build Numbers and Release Dates Export Messages from Queues Fax Advisor for Exchange 2010 Filterable Properties for the -Filter Parameter Get-MailboxAuditBypassAssociation How Retention Age is Calculated How to Import the Exchange 2010 Monitoring Management Pack Install or Upgrade to Exchange 2010 SP2 Unified Messaging Managing Connectors MSExchange ADAccess 2915 MSExchange ADAccess 2916 New-MailContact New Unified Messaging Functionality and Voice Mail Features in Exchange 2010 SP1 Optional Configurations Protecting Journal Reports Regular Expressions in Transport Rules Release Notes for Exchange Server 2010 SP2 Set-ActiveSyncMailboxPolicy Set-DynamicDistributionGroup Set-ImapSettings Set-Mailbox Set-PopSettings Set-RemoteDomain Start-RetentionAutoTagLearning Start the MRSProxy Service on a Remote Client Access Server Transport Rule Predicates Troubleshooting the Exchange Management Pack Understanding Alert Correlation Understanding Calendar Repair Understanding Client Throttling Policies Understanding Exchange 2010 Virtualization Understanding Exchange ActiveSync Reporting Services Understanding Federated Delegation Understanding Management Role Scopes Understanding Monitoring Management Pack Operations Understanding POP3 and IMAP4 Understanding Recipient Filtering Understanding Retention Tags and Retention Policies Understanding Safelist Aggregation Understanding the Availability Service Understanding the Exchange Management Pack Health State Model Understanding Transport Database Configuration Options Understanding Unified Messaging Languages Update-SafeList Use Windows Server Backup to Restore a Backup of Exchange Voice Mail Preview Advisor for Exchange 2010

September 2012
New Content Modify the Time Limit for Autodiscover Operations Understanding Database Maintenance Updated Content Antispam Update Errors and Events Configure an Ethical Wall Configure Autodiscover Redirection for the Multi-Tenant Organization Configure Calendar Repair Assistant Settings Configure SSL for Exchange ActiveSync Configure SSL for Outlook Anywhere Configure the Automated Booking Policies for a Resource Mailbox Configure the Availability Service for Cross-Forest Topologies Enable or Disable Calendar Repair for a Mailbox Enable or Disable Mailbox Audit Logging for a Mailbox Exchange Network Port Reference Exchange Server Build Numbers and Release Dates ExchangeStoreDB Errors and Events File-Level Antivirus Scanning on Exchange 2010 New-MoveRequest Obtain a Server Certificate from a Certification Authority Optional Configurations Restore-Mailbox

Scripts for Managing Public Folders in the Exchange Management Shell Session Border Controllers Tested with Exchange Online UM Set-ActiveSyncOrganizationSettings Set-CalendarProcessing Set-TransportServer Set-CASMailbox Set-Mailbox Set-MailboxServer Set-OwaMailboxPolicy Set-OwaVirtualDirectory Set-TransportServer Troubleshooting Reference for Client Access Servers Understanding Calendar Repair Understanding Client Throttling Policies Understanding Database and Log Performance Factors Understanding Digital Certificates and SSL Understanding Information Rights Management Understanding Mailbox Audit Logging Understanding Mobile Phone Connectivity Understanding Outlook Anywhere Understanding RPC Client Access Understanding Storage Configuration

August 2012
Updated Content Client Access Server Counters Configure Calendar Repair Log Settings Configure Exchange Online Archiving Configure Language Settings for Outlook Web App Configure Shadow Redundancy Configure the Availability Service for Cross-Forest Topologies Disable a Mobile Phone for Exchange ActiveSync Enable a Device for Exchange ActiveSync Exchange Server Build Numbers and Release Dates Managing Outlook Web App Security New Transport Functionality in Exchange 2010 SP1 Overview of Administrator Audit Logging Overview of Services Installed by Exchange Setup Overview of Unified Messaging Release Notes for Exchange Server 2010 SP2 Remove Public Folder Databases Understanding Client Throttling Policies Understanding Exchange 2010 Virtualization Understanding Personal Archives Understanding Shadow Redundancy

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

What's New in Exchange 2010 SP3

Applies to: Exchange Server 2010 SP3 Topic Last Modified: 2013-06-28 This topic provides you with an overview of important new features and functionality in Service Pack 3 (SP3) for Microsoft Exchange Server 2010. This overview can be useful when youre planning, deploying, and administering your organization. The following sections include information about changes to features and functionality that have occurred since the release of Microsoft Exchange Server 2010 Service Pack 2 (SP2):

Exchange 2013 Coexistence Support Sent Items Management Feature Windows Server 2012 In addition to the changes described in this topic, Exchange 2010 SP3 also includes fixes that address issues identified since the release of Exchange 2010 SP2. For a complete list of issues that are fixed in Exchange 2010 SP3, see Issues That Are Fixed in Exchange 2010 SP3. If you're also interested in the release notes for Exchange 2010 SP3, see Release Notes for Exchange Server 2010 SP3. For more information about the features introduced in previous versions of Exchange 2010, see the following topics:

What's New in Exchange 2010 SP2 What's New in Exchange 2010 SP1 What's New in Exchange 2010

Exchange 2013 Coexistence Support

You must install Exchange 2010 SP3 if you want to run Microsoft Exchange Server 2013 in a coexistence mode. You can't perform an in-place upgrade from Exchange 2010 to Exchange 2013. However, you can install an Exchange 2013 Cumulative Update 1 (CU1) server in the existing Exchange 2010 organization after you install Exchange 2010 SP3. For more information about how to install an Exchange 2013 server in the existing organization, see Install Exchange 2013 in an Existing Exchange 2010 Organization. After you perform this procedure, your organization will be running in a coexistence mode. You can maintain this mode indefinitely, or you can immediately complete the upgrade to Exchange 2013 by moving all resources from Exchange 2010 to Exchange 2013, and then decommissioning the Exchange 2010 servers. For more information about how to upgrade to Exchange 2013, see Upgrade from Exchange 2010 to Exchange 2013.

Sent Items Management Feature

Exchange 2010 SP3 introduces the Sent Items Management feature to Office Outlook Web Access(OWA). The Sent Items Management feature provides control over whether an item that is sent as you, or on behalf of you, is copied to your Sent Items folder and to the senders Sent Items folder. Before Exchange 2010 SP3, messages that are sent as you or on behalf of you are copied only to the sender's Sent Items folder. You can configure the Sent Items Management feature in OWA on the Options page. After Exchange 2010 SP3 is installed, the Sent Items Options settings will be available on the Options page in OWA.

Windows Server 2012

Exchange 2010 SP3 can be used with Windows Server 2012. For more information about operating system supportability, see Exchange Server Supportability Matrix.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Release Notes for Exchange Server 2010 SP3

Applies to: Exchange Server 2010 SP3 Topic Last Modified: 2013-05-07 For important legal information, see Legal Notice later in this document. Welcome to Service Pack 3 (SP3) for Microsoft Exchange Server 2010. This document contains the following sections:

Installing Exchange 2010 SP3 Database Schema Upgrades Legal Notice

Installing Exchange 2010 SP3

Consider the following when you deploy Exchange 2010 SP3:

Exchange 2010 SP3 makes updates to the Active Directory schema. To learn more about these schema changes, see Exchange Server Changes to the Active Directory Schema. You can select an option that installs the required Windows operating system roles and features for each selected Exchange 2010 SP3 server role. You can install Exchange 2010 SP3 only on computers that are running Windows Server 2008 with Service Pack 2 (SP2), Windows Server 2008 R2, or Windows Server 2012. For detailed information about the requirements and steps for installing Exchange 2010 SP3, see the following topics:

Exchange 2010 Prerequisites Exchange 2010 System Requirements Understanding a New Installation of Exchange 2010 Understanding Upgrade to Exchange 2010

Database Schema Upgrades

The database schema for Exchange 2010 has been updated in Exchange 2010 SP1. Because SP3 contains all the fixes included in SP2 and SP1, when Exchange 2010 RTM Mailbox servers are upgraded to SP3, the databases are upgraded to the Exchange 2010 SP1 version of the database schema. This database schema upgrade process adds time to the overall service pack upgrade process. During the upgrade, the database is dismounted, and all mailboxes in that database are taken offline. If you're upgrading the Mailbox server from the release to manufacturing (RTM) version of Exchange 2010 to Exchange 2010 SP3, the database upgrade process could take an additional 30 minutes or longer per database. You can track the progress of the database upgrade process by examining event 1185 in the Application event log on the server you're upgrading. After a database has been updated to the Exchange 2010 SP3 schema, it can't be mounted on a RTM Mailbox server. If you're upgrading from Exchange 2010 SP2 or SP1 to Exchange 2010 SP3, the upgrade process takes less time, because there is no database schema upgrade. In addition, you can safely move a database between servers running Exchange 2010 SP1, SP2 or SP3. Even though you can move databases between mailbox servers running different service pack levels, you should complete the upgrade of all DAG members to the same service pack level without too much delay. We recommend that you minimize the amount of time you have your DAG members running different service pack levels.

Legal Notice
This document is provided as-is. Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it. Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred. This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal reference purposes. 2011 Microsoft Corporation. All rights reserved. Microsoft, MS-DOS, Windows, Windows Media, Windows Mobile, Windows NT, Windows PowerShell, Windows Server, Windows Vista, Active Directory, ActiveSync, Entourage, Excel, Forefront, Internet Explorer, Outlook, PowerPoint, SharePoint, SmartScreen, Visual Basic, Xbox, Xbox 360, the Xbox sphere logo, Zune, and the Zune logo are trademarks of the Microsoft group of companies. All other trademarks are property of their respective owners. Arabic Spelling Checker, Grammar Checker, and Thesaurus, 1992-2006 developed by COLTEC Egypt. All rights reserved. Italian grammar checker with Cogito technology 1994-2006 Expert System Modena. All rights reserved. Italian thesaurus 1994-2006 Expert System Modena. All rights reserved. Brazilian Portuguese Speller, Hyphenator, Thesaurus and Grammar. Itautec Philco S.A., Grupo Itautec Philco Danish speller: Copyright Lingsoft, Inc. 2005. Two-Level Compiler: Copyright Xerox Corporation 1994. All rights reserved.

Danish hyphenator: Copyright Lingsoft, Inc. 2005. Two-Level Compiler. Copyright Xerox Corporation 1994. All rights reserved. German speller. Copyright Lingsoft, Inc. 2005. Two-Level Compiler: Copyright Xerox Corporation 1994. All rights reserved. German hyphenator. Copyright Lingsoft, Inc. 2005. Two-Level Compiler: Copyright Xerox Corporation 1994. All rights reserved. German inflecting thesaurus: Copyright Lingsoft, Inc. 2005. German thesaurus: Copyright Karl Peltzer and Reinhard von Norman and Ott Verlag and Druck AG Thun/Switzerland 1996. Two-Level Compiler: Copyright Xerox Corporation 1994. All rights reserved. Norwegian bokml speller: Copyright Lingsoft, Inc. 2005. Norwegian works: Copyright J. W. Cappelens Forlag AS 1996, 1997: Norsk ordbok: Bokml: Copyright J. W. Cappelens Forlag AS 1996. CAPLEX: Copyright J. W. Cappelens Forlag AS 1997. Two-Level Compiler: Copyright Xerox Corporation 1994. All rights reserved. Norwegian bokml hyphenator: Copyright Lingsoft, Inc. 2005. Norwegian works: Copyright J. W. Cappelens Forlag AS 1996, 1997: Norsk ordbok: Bokml: Copyright J. W. Cappelens Forlag AS 1996. CAPLEX: Copyright J. W. Cappelens Forlag AS 1997. Two-Level Compiler. Copyright Xerox Corporation 1994. All rights reserved. Norwegian nynorsk speller: Copyright Lingsoft, Inc. 2005. February 1998 electronic version of Nynorskordboka: Copyright University of Oslo and The Norwegian Language Council 1998. Two-Level Compiler. Copyright Xerox Corporation 1994. All rights reserved. Norwegian nynorsk hyphenator: Copyright Lingsoft, Inc. 2005. February 1998 electronic version of Nynorskordboka: Copyright University of Oslo and The Norwegian Language Council 1998. Two-Level Compiler: Copyright Xerox Corporation 1994. All rights reserved. Swedish grammar checker: Copyright Lingsoft, Inc. 2005. Constraint Grammar Parser: Copyright Pasi Tapanainen 1993 and Lingsoft, Inc. 2005. Two-Level Compiler: Copyright Xerox Corporation 1994. All rights reserved. Hebrew thesaurus and Hebrew language spell checker, 2009 Melingo. All rights reserved. Portuguese Spell Checker, Hyphenator, Grammar Checker and Thesaurus 1995-2005 Priberam Informtica, Lda. Thesauruss content based on dictionrio de Sinnimos from Porto Editora, Lda. All rights reserved. Portions of security system based on BSAFE and TIPEM software from RSA Data Security, Inc. ORFOTM Grammar Checker JSC Informatics, 1990-2002. All rights reserved. , 1990-2002. . The following components are licensed to Microsoft in object code form by Stellent Chicago Sales, Inc.: Components Version 8.0 Outside In HTML Export Version 8.0

Platforms Supported Version 8.0: Windows Intel (32 bit binaries) Windows 2000/XP/Server 2003 Windows Itanium (64 bit binaries) Windows.NET Server 2003 Enterprise Edition for Itanium Windows AMD (64 bit binaries) Windows Server 2003, Enterprise Edition for AMD Opteron

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Issues That Are Fixed in Exchange 2010 SP3

Applies to: Exchange Server 2010 SP3 Topic Last Modified: 2013-01-25 This topic lists the issues that are fixed in Microsoft Exchange Server 2010 Service Pack 3 (SP3). For more information about Exchange 2010 SP3, see the following topics:

To learn more about the new features in Exchange 2010 SP3, see What's New in Exchange 2010 SP3. To learn more about known issues that affect Exchange 2010 SP3, see Release Notes for Exchange Server 2010 SP3. To obtain Exchange 2010 SP3, see Exchange Server 2010 Service Pack 3.

Issues that are fixed

Exchange 2010 SP3 includes the changes that were made in the following Exchange 2010 SP2 rollups:

Description of Update Rollup 1 for Exchange Server 2010 Service Pack 2 Description of Update Rollup 2 for Exchange Server 2010 Service Pack 2 Description of Update Rollup 3 for Exchange Server 2010 Service Pack 2 Description of Update Rollup 4 for Exchange Server 2010 Service Pack 2 Description of Update Rollup 4 Version 2 for Exchange Server 2010 SP2 Description of Update Rollup 5 version 2 for Exchange Server 2010 Service Pack 2

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

What's New in Exchange 2010 SP2

Exchange 2010 Applies to: Exchange Server 2010 SP2 Topic Last Modified: 2012-05-11 This topic provides you with an overview of important new features and functionality in Service Pack 2 (SP2) for Microsoft Exchange Server 2010, which can be useful when youre planning, deploying, and administering your organization. The following sections include information about changes to features and functionality that has occurred since Service Pack 1 (SP1) for Exchange 2010:

Hybrid Configuration Wizard Federated Delegation Address Book Policies Cross-Site Silent Redirection for Outlook Web App Mini Version of Outlook Web App Mailbox Replication Service Mailbox Auto-Mapping Multi-Valued Custom Attributes Litigation Hold Multi-Tenant Support In addition to the changes described in this topic, Exchange 2010 SP2 also includes fixes that address issues identified since the release of Exchange 2010 SP1. For a complete list of issues fixed in Exchange 2010 SP2, see Issues That Are Fixed in Exchange 2010 SP2. If you're also interested in the release notes for Exchange 2010 SP2, see Release Notes for Exchange Server 2010 SP2. For more information about the features introduced in previous versions of Exchange 2010, see the following topics:

What's New in Exchange 2010 What's New in Exchange 2010 SP1

Hybrid Configuration Wizard

Exchange 2010 SP2 introduces the Hybrid Configuration Wizard which provides you with a streamlined process to configure a hybrid deployment between on-premises and Office 365 Exchange organizations. Hybrid deployments provide the seamless look and feel of a single Exchange organization and offer administrators the ability to extend the feature-rich experience and administrative control of an on-premises organization to the cloud. For more information, see Understanding the Hybrid Configuration Wizard.

Federated Delegation
In Exchange 2010 SP1, we recommended that organizations create a sub-domain of exchangedelegation for the account namespace in their federation trust with the Microsoft Federation Gateway. Now, in Exchange 2010 SP2, we have updated our recommendation and also automated the configuration process. If you use the Manage Federation or Manage Hybrid Configuration wizards when configuring a new federation trust, a pre-defined string is now automatically combined with an accepted domain for your organization and assigned as the account namespace for the federation trust. The account namespace for an existing federation trust is not modified by these wizards. For more information, see Understanding Federation.

Address Book Policies

Exchange 2010 SP2 introduces the address book policy object which can be assigned to a mailbox user. The ABP determines the global address list (GAL), offline address book (OAB), room list, and address lists that are visible to the mailbox user that is assigned the policy. Address book policies provide a simpler mechanism to accomplish GAL separation for the on-premises organization that needs to run disparate GALs. For more information, see Understanding Address Book Policies.

Cross-Site Silent Redirection for Outlook Web App

With Exchange 2010 SP2, you can enable a silent redirection when a Client Access server receives a client request that is better serviced by a Client Access server located in another Active Directory site. This silent redirection can also provide a single sign-on experience when forms-based authentication is enabled on each Client Access server. For more information, see Understanding Proxying and Redirection.

Mini Version of Outlook Web App

The mini version of Outlook Web App is a lightweight browser-based client, similar to the Outlook Mobile Access client in Exchange 2003. Its designed to be used on a mobile operating system. The mini version of Outlook Web App provides users with the following basic functionality:

Access to e-mail, calendar, contacts, tasks and the global address list. Access to e-mail subfolders. Compose, reply to, and forward e-mail messages. Create and edit calendar, contact, and task items. Handle meeting requests. Set the time zone and automatic reply messages. For more information, see Understanding the Mini Version of Outlook Web App.

Mailbox Replication Service

In Exchange 2010 SP1, if you wanted to move mailboxes from on-premises to Outlook.com or to another forest, you had to enable MRSProxy on the remote Client Access server. To do this, you had to manually configure the web.config file on every Client Access server. In Exchange 2010 SP2, two parameters have been added to the New-WebServicesVirtualDirectory and Set-WebServicesVirtualDirectory cmdlets so that you don't have to perform the manual configuration: MRSProxyEnabled and MaxMRSProxyConnections. For more information, see Start the MRSProxy Service on a Remote Client Access Server.

Mailbox Auto-Mapping
In Exchange 2010 SP1, Office Outlook 2007 and Outlook 2010 clients can automatically map to any mailbox to which a user has Full Access permissions. If a user is granted Full Access permissions to another user's mailbox or to a shared mailbox, Outlook, through Autodiscover, automatically loads all mailboxes to which the user has full access. However, if the user has full access to a large number of mailboxes, performance issues may occur when starting Outlook. Therefore, in Exchange 2010 SP2, administrators can turn off the auto-mapping feature by setting the value of the new Automapping parameter to $false on the Add-MailboxPermission cmdlets. For more information, see Disable Outlook Auto-Mapping with Full Access Mailboxes.

Multi-Valued Custom Attributes

Exchange 2010 SP2 introduces five new multi-value custom attributes that you can use to store additional information for mail recipient objects. The ExtensionCustomAttribute1 to ExtensionCustomAttribute5 parameters can each hold up to 1,300 values. You can specify multiple values as a comma-delimited list.The following cmdlets support these new parameters:

Set-DistributionGroup Set-DynamicDistributionGroup Set-Mailbox Set-MailContact Set-MailPublicFolder Set-RemoteMailbox

Litigation Hold
In Exchange 2010 SP2, you cant disable or remove a mailbox that has been placed on litigation hold. To bypass this restriction, you must either remove litigation hold from the mailbox, or use the new IgnoreLegalHold switch parameter when removing or disabling the mailbox. The IgnoreLegalHold parameter has been added to the following cmdlets:

Disable-Mailbox Remove-Mailbox Disable-RemoteMailbox Remove-RemoteMailbox Disable-MailUser Remove-MailUser

Multi-Tenant Support
Exchange 2010 SP1 introduced the ability to install in a hosting mode by using the /hosting switch when running the installation script. However, in Exchange 2010 SP2, we no longer recommend installing Exchange using the /hosting switch. To learn more, see Multi-Tenant Support.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Release Notes for Exchange Server 2010 SP2

Exchange 2010 Applies to: Exchange Server 2010 SP2 Topic Last Modified: 2013-05-07 For important legal information, see Legal Notice later in this document. Welcome to Service Pack 2 (SP2) for Microsoft Exchange Server 2010. This document contains the following sections:

Installing Exchange 2010 SP2 Setup Database Schema Upgrades Client Access Server Prerequisite Changes Role Based Access Control Outlook Web App Mailbox Replication Proxy Shadow Redundancy Promotion Feature Legal Notice

Installing Exchange 2010 SP2

Consider the following when you deploy Exchange 2010 SP2:

Exchange 2010 SP2 makes updates to the Active Directory schema. To learn more about these schema changes, see Exchange Server Changes to the Active Directory Schema. You can select an option that installs the required Windows operating system roles and features for each selected Exchange 2010 SP2 server role. You can only install Exchange 2010 SP2 on computers running the Windows Server 2008 operating system with Service Pack 2 (SP2) and the Windows Server 2008 R2 operating system. For detailed information about the requirements and steps for installing Exchange 2010 SP2, see the following topics:

Exchange 2010 Prerequisites Exchange 2010 System Requirements Understanding a New Installation of Exchange 2010 Understanding Upgrade to Exchange 2010

Setup
When you upgrade from a previous version of Exchange 2010 to Exchange 2010 SP2 and youve previously defined the execution policy of Windows PowerShell scripts using group policies, Setup will fail. After Setup fails, Exchange 2010 will no longer work on the affected server and you wont be able to restart Setup. This issue happens because a required service is stopped by Setup during installation. This service is needed to query Active Directory Domain Services to verify the execution policy of Windows PowerShell scripts that must run as part of Setup. To avoid this issue, do the following:

1. Use the Group Policy Management Console to disable the group policy. The Windows PowerShell execution policy group policy objects must be set to Undefined. 2. Install Exchange 2010 SP2. 3. Re-enable the previously defined Windows PowerShell execution policy through the Group Policy Management Console. For more information about this issue, or if youve already run Setup and have encountered an error, see Microsoft Knowledge Base article 2668686, Error message when you try to install Exchange Server 2010 SP2: "AuthorizationManager check failed".

Database Schema Upgrades

The database schema for Exchange 2010 has been updated in Exchange 2010 SP1. Because SP2 contains all the fixes included in SP1, when Exchange 2010 RTM Mailbox servers are upgraded to SP2, the databases are upgraded to the Exchange 2010 SP1 version of the database schema. This database schema upgrade process adds time to the overall service pack upgrade process. During the upgrade, the database is dismounted, and all mailboxes in that database are taken offline. If you're upgrading the Mailbox server from the release to manufacturing (RTM) version of Exchange 2010 to Exchange 2010 SP2, the database upgrade process could take an additional 30 minutes or longer per database. You can track the progress of the database upgrade process by examining event 1185 in the Application event log on the server you're upgrading. After a database has been updated to the Exchange 2010 SP2 schema, it can't be mounted on a RTM Mailbox server. If you're upgrading from Exchange 2010 SP1 to Exchange 2010 SP2, the upgrade process takes less time, because there is no database schema upgrade. In addition, you can safely move a database between servers running Exchange 2010 SP1 and SP2. Even though you can move databases between mailbox servers running different service pack levels, you should complete the upgrade of all DAG members to the same service pack level without too much delay. We recommend that you minimize the amount of time you have your DAG members running different service pack levels.

Client Access Server Prerequisite Changes

Several new prerequisites have been added when installing the Client Access server role. Prior to installing Exchange 2010 SP2, you must install these new prerequisites

on servers that have the Client Access server role installed. If the prerequisites aren't installed, Setup will fail. To install the prerequisites on Client Access servers, do the following: Windows Server 2008 SP2

1. 2. 3. 4.

Open Server Manager. Select Roles. Under Web Server (IIS), select Add Role Services. In the Add Role Services wizard, on the Select Role Services page, select the following Windows features: IIS 6 WMI Compatibility ASP.NET ISAPI Filters Client Certificate Mapping Authentication Directory Browsing HTTP Errors HTTP Logging HTTP Redirection Tracing Request Monitor Static Content 5. Click Next and then Install. Windows Server 2008 R2

1. On the Start menu, navigate to All Programs > Accessories > Windows PowerShell. Open an elevated Windows PowerShell console, and run the following command:

Import-Module ServerManager

2. Add the prerequisites by running the following command:

Add-WindowsFeature Web-WMI,Web-Asp-Net,Web-ISAPI-Filter,Web-Client-Auth,Web-Dir-Browsing,Web-Http-Errors,Web-Http-Logging,Web-Http-Redirect,Web

If you want Exchange to install the new prerequisites during Setup, you can use unattended mode. Run the following command:

Setup /Mode:Upgrade /InstallWindowsComponents

Role Based Access Control

When you first install Exchange 2010 SP2 on an Exchange 2010 server in your organization, some Role Based Access Control (RBAC) management role definitions are updated in Active Directory. If you have multiple Exchange 2010 servers and you attempt to manage these roles from an Exchange 2010 server that hasn't been upgraded to Exchange 2010 SP2, you might receive one of the following warnings:

Exchange Management Shell WARNING: The object MyMailboxDelegation has been corrupted, and it's in an inconsistent state. The following validation errors happened: WARNING: The property value you specified, "15", isn't defined in the Enum type "ScopeType". Exchange 2010 Control Panel There are multiple warnings. Click here to see more The object MyMailboxDelegation has been corrupted, and it's in an inconsistent state. The following validation errors happened: The property value you specified, "15", isn't defined in the Enum type "ScopeType". To resolve the warnings, upgrade the server to Exchange 2010 SP2. The cause of these warnings doesn't prevent Exchange 2010 from functioning correctly and can safely be ignored until the server is upgraded to Exchange 2010 SP2.

Outlook Web App

If youre using redirection for Outlook Web App and arent requiring Secure Sockets Layer SSL, redirection will fail after the Client Access server is upgraded to Exchange 2010 SP2. To avoid this problem, after youve completed the upgrade to Exchange 2010 SP2, modify the Outlook Web App web.config file. For directions, go to Use IIS Manager and Notepad to simplify the Outlook Web App URL when SSL isnt required in Simplify the Outlook Web App URL. You dont have to make any changes in IIS Manager to prevent redirection from failing. You just have to modify the web.config file.

Mailbox Replication Proxy

When you upgrade to Exchange 2010 SP2, the Mailbox Replication Proxy (MRSProxy) service is disabled by Exchange if it was previously enabled. This happens because the way MRSProxy is enabled has changed in Exchange 2010 SP2 and the settings in the <Exchange Installation Path>\V14\ClientAccess\ExchWeb\EWS\web.config file are not migrated during the upgrade. Until MRSProxy is re-enabled, cross-forest mailbox move requests will not be processed. In Exchange 2010 SP2, MRSProxy is enabled by using the MRSProxyEnabled parameter on the Set-WebServicesVirtualDirectory cmdlet. You must manually enable MRSProxy after you upgrade to Exchange 2010 SP2. MRSProxy must be manually re-enabled on each server where it was previously enabled. For more information

about how to enable MRSProxy in Exchange 2010 SP2, see Start the MRSProxy Service on a Remote Client Access Server. Prior to Exchange 2010 SP2, MRSProxy configuration was stored in the <Exchange Installation Path>\V14\ClientAccess\ExchWeb\EWS\web.config file. The settings stored in this file are no longer used by MRSProxy in Exchange 2010 SP2 and should not be changed.

Shadow Redundancy Promotion Feature

When you install Service Pack 2 for Exchange 2010, the value of the Shadow Redundancy Promotion feature is reset to False, and the setting is disabled. If you enabled Shadow Redundancy in your Exchange 2010 SP1 organization, you must re-enable Shadow Redundancy after you install Exchange 2010 SP2. Note that other settings in EdgeTransport.exe.config are not reset when you install Exchange 2010 SP2.

Legal Notice
This document is provided as-is. Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it. Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred. This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes. 2011 Microsoft Corporation. All rights reserved. Microsoft, MS-DOS, Windows, Windows Media, Windows Mobile, Windows NT, Windows PowerShell, Windows Server, Windows Vista, Active Directory, ActiveSync, Entourage, Excel, Forefront, Internet Explorer, Outlook, PowerPoint, SharePoint, SmartScreen, Visual Basic, Xbox, Xbox 360, the Xbox sphere logo, Zune, and the Zune logo are trademarks of the Microsoft group of companies. All other trademarks are property of their respective owners. Arabic Spelling Checker, Grammar Checker, and Thesaurus, 1992-2006 developed by COLTEC Egypt. All rights reserved. Italian grammar checker with Cogito technology 1994-2006 Expert System Modena. All rights reserved. Italian thesaurus 1994-2006 Expert System Modena. All rights reserved. Brazilian Portuguese Speller, Hyphenator, Thesaurus and Grammar. Itautec Philco S.A., Grupo Itautec Philco Danish speller: Copyright Lingsoft, Inc. 2005. Two-Level Compiler: Copyright Xerox Corporation 1994. All rights reserved. Danish hyphenator: Copyright Lingsoft, Inc. 2005. Two-Level Compiler. Copyright Xerox Corporation 1994. All rights reserved. German speller. Copyright Lingsoft, Inc. 2005. Two-Level Compiler: Copyright Xerox Corporation 1994. All rights reserved. German hyphenator. Copyright Lingsoft, Inc. 2005. Two-Level Compiler: Copyright Xerox Corporation 1994. All rights reserved. German inflecting thesaurus: Copyright Lingsoft, Inc. 2005. German thesaurus: Copyright Karl Peltzer and Reinhard von Norman and Ott Verlag and Druck AG Thun/Switzerland 1996. Two-Level Compiler: Copyright Xerox Corporation 1994. All rights reserved. Norwegian bokml speller: Copyright Lingsoft, Inc. 2005. Norwegian works: Copyright J. W. Cappelens Forlag AS 1996, 1997: Norsk ordbok: Bokml: Copyright J. W. Cappelens Forlag AS 1996. CAPLEX: Copyright J. W. Cappelens Forlag AS 1997. Two-Level Compiler: Copyright Xerox Corporation 1994. All rights reserved. Norwegian bokml hyphenator: Copyright Lingsoft, Inc. 2005. Norwegian works: Copyright J. W. Cappelens Forlag AS 1996, 1997: Norsk ordbok: Bokml: Copyright J. W. Cappelens Forlag AS 1996. CAPLEX: Copyright J. W. Cappelens Forlag AS 1997.

Two-Level Compiler. Copyright Xerox Corporation 1994. All rights reserved. Norwegian nynorsk speller: Copyright Lingsoft, Inc. 2005. February 1998 electronic version of Nynorskordboka: Copyright University of Oslo and The Norwegian Language Council 1998. Two-Level Compiler. Copyright Xerox Corporation 1994. All rights reserved. Norwegian nynorsk hyphenator: Copyright Lingsoft, Inc. 2005. February 1998 electronic version of Nynorskordboka: Copyright University of Oslo and The Norwegian Language Council 1998. Two-Level Compiler: Copyright Xerox Corporation 1994. All rights reserved. Swedish grammar checker: Copyright Lingsoft, Inc. 2005. Constraint Grammar Parser: Copyright Pasi Tapanainen 1993 and Lingsoft, Inc. 2005. Two-Level Compiler: Copyright Xerox Corporation 1994. All rights reserved. Hebrew thesaurus and Hebrew language spell checker, 2009 Melingo. All rights reserved. Portuguese Spell Checker, Hyphenator, Grammar Checker and Thesaurus 1995-2005 Priberam Informtica, Lda. Thesauruss content based on dictionrio de Sinnimos from Porto Editora, Lda. All rights reserved. Portions of security system based on BSAFE and TIPEM software from RSA Data Security, Inc. ORFOTM Grammar Checker JSC Informatics, 1990-2002. All rights reserved. , 1990-2002. . The following components are licensed to Microsoft in object code form by Stellent Chicago Sales, Inc.: Components Version 8.0 Outside In HTML Export Version 8.0 Platforms Supported Version 8.0: Windows Intel (32 bit binaries) Windows 2000/XP/Server 2003 Windows Itanium (64 bit binaries) Windows.NET Server 2003 Enterprise Edition for Itanium Windows AMD (64 bit binaries) Windows Server 2003, Enterprise Edition for AMD Opteron

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Issues That Are Fixed in Exchange 2010 SP2

Exchange 2010 Applies to: Exchange Server 2010 SP2 Topic Last Modified: 2011-11-29 This topic provides the list of issues that are fixed in Microsoft Exchange Server 2010 Service Pack 2 (SP2). For additional information about Exchange Server 2010 SP2, see the following:

To learn more about the new features in Exchange Server 2010 SP2, see What's New in Exchange 2010 SP2. To learn more about known issues with SP2, see Release Notes for Exchange Server 2010 SP2. To obtain Exchange Server 2010 SP2, see Exchange Server 2010 Service Pack 2.

Issues that are Fixed

Exchange 2010 SP2 includes the changes made in the following Exchange 2010 SP1 rollups:

Update Rollup 6 for Exchange Server 2010 Service Pack 1 Update Rollup 5 for Exchange Server 2010 Service Pack 1 Update Rollup 4 for Exchange Server 2010 Service Pack 1 Update Rollup 3 for Exchange Server 2010 Service Pack 1 Update Rollup 2 for Exchange Server 2010 Service Pack 1 Update Rollup 1 for Exchange Server 2010 Service Pack 1

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Multi-Tenant Support
Exchange 2010 Applies to: Exchange Server 2010 SP2 Topic Last Modified: 2011-12-01 A multi-tenant Exchange deployment is defined in this topic as one where the system has been configured to host multiple and discrete organizations or business units (the tenants that ordinarily dont share e-mail, data, users, global address lists GALs, or any other commonly used Exchange objects. In Exchange 2010 Service Pack 1 (SP1), Exchange introduced the ability to install in a hosting mode by using the /hosting switch when running the installation script. However, in Exchange 2010 SP2, we no longer recommend installing Exchange using the /hosting switch. To learn more, see the Exchange Team Blog article Future of /Hosting Mode. In Exchange 2010 SP2, hosting is supported by using the on-premises Exchange installation. For guidance about configuring a multi-tenant organization with Exchange 2010 SP2, download the white paper Multi-Tenancy and Hosting Guidance for Exchange Server 2010 SP2. This paper doesnt provide step-by-step instructions about how to achieve multi-tenancy with Exchange 2010 SP2. Instead, it provides information about the challenges and problems that must be solved, and offers advice and direction to ensure the Exchange environment you build can be supported by Microsoft. 2010 Microsoft Corporation. All rights reserved.
2013 Microsoft. All rights reserved.

What's New in Exchange 2010 SP1

Exchange 2010 Applies to: Exchange Server 2010 SP1 Topic Last Modified: 2012-07-23 This topic provides you with an overview of important new features and functionality in Exchange Server 2010 Service Pack 1 (SP1), which you can use when you're planning, deploying, and administering your organization. The following sections include information about changes to features and functionality that has occurred since Exchange Server 2010 RTM (release to manufacturing) and information about features and functionality first introduced in Exchange 2010 SP1. For more information about the features and functionality that was introduced at Exchange 2010 RTM, see What's New in Exchange 2010. For information about known issues with Exchange 2010 SP1, see Release Notes for Exchange Server 2010 SP1. In addition to the changes described in this topic, Exchange 2010 SP1 also includes fixes that address issues identified since the release of Exchange 2010 RTM. For a complete list, see Issues That Are Fixed in Exchange 2010 SP1.

New Deployment Functionality

During an Exchange 2010 SP1 installation, you can now select a new option to install the required Windows roles and features for each selected Exchange 2010 SP1 server role. For more information, see New Deployment Functionality in Exchange 2010 SP1.

Client Access Server Role Improvements

The improvements and new features in the Client Access server role fall under several key areas: Federation certificates, Exchange ActiveSync, SMS Sync, Integrated Rights Management, Microsoft Office Outlook Web App, and virtual directories. Each area is described in more detail in the following sections.

Federation Certificates
In Exchange 2010 SP1, you can use a self-signed certificate instead of a certificate issued by a Certificate Authority to establish a federation trust with the Microsoft Federation Gateway. A self-signed certificate is automatically created and installed on Exchange servers in your organization when you use the New Federation Trust wizard in the Exchange Management Console. For more information, see Understanding Federation.

Exchange ActiveSync
In Exchange 2010 SP1, you can manage Exchange ActiveSync devices using the Exchange Control Panel (ECP). Administrators can perform the following tasks:

Manage the default access level for all mobile phones and devices. Set up e-mail alerts when a mobile phone or device is quarantined. Personalize the message that users receive when their mobile phone or device is either recognized or quarantined. Provide a list of quarantined mobile phones or devices. Create and manage Exchange ActiveSync device access rules. Allow or block a specific mobile phone or device for a specific user. For every user, the administrator can perform the following tasks from the user's property pages:

List the mobile phones or devices for a specific user. Initiate remote wipes on mobile phones or devices. Remove old mobile phone or device partnerships. Create a rule for all users of a specific mobile phone or device or mobile phone type. Allow or block a specific mobile phone or device for the specific user. For more information, see Understanding Exchange ActiveSync.

SMS Sync
SMS Sync is a new feature in Exchange ActiveSync that works with Windows Mobile 6.1 with the Outlook Mobile Update and with Windows Mobile 6.5. SMS Sync is the ability to synchronize messages between a mobile phone or device and an Exchange 2010 Inbox. When synchronizing a Windows Mobile phone with an Exchange 2010 mailbox, users can choose to synchronize their text messages in addition to their Inbox, Calendar, Contacts, Tasks, and Notes. When synchronizing text messages, users will be able to send and receive text messages from their Inbox. This feature is dependent on the user's mobile phones or devices supporting this feature.

Server-Side Information Rights Management Support

Exchange ActiveSync mailbox policies now contain support for Information Rights Management (IRM) functionality. Information Rights Management is enabled when creating a new Exchange ActiveSync mailbox policy. This new functionality allows non-Windows Mobile devices to receive and view protected e-mails. When the IRMEnabled property is configured on the Exchange ActiveSync mailbox policy and IRM is enabled for Client Access Servers, the protected e-mail will be decrypted on the server before it is downloaded to the mobile phone or device. The downloaded e-mail will be downloaded with additional properties that indicate the restrictions sent with the original e-mail. Protected messages will only be decrypted and downloaded if the mobile phone or device connects to the Client Access server using

Secure Sockets Layer (SSL).

Outlook Web App Improvements

The following is a list of the new Outlook Web App functionality in Exchange 2010 SP1:

Improved management of the relationship between Office Communications Server and Outlook Web App. Configuration is stored in Active Directory instead of a web.config file and can be managed via cmdlet. Twenty-seven themes are available, and they have new administrative options: Set default theme with the DefaultTheme parameter by using either the Set-OwaMailboxPolicy or the Set-OwaVirtualDirectory cmdlet. Create custom themes by modifying existing themes. Control the order themes are listed in Outlook Web App. By default, attachment types that are marked as Force Save will be excluded from security checks for XML or HTML. You can change this behavior by setting the ForceSaveAttachmentFilteringEnabled parameter to $true by using either the Set-OwaMailboxPolicy or the Set-OwaVirtualDirectory cmdlet. Users can change unexpired passwords by default. In Exchange 2010 SP1, you can also enable users to reset expired passwords. See Configuring the Change Password Feature in Outlook Web App.

Reset Virtual Directory

In Exchange 2010 SP1, you can use the new Reset Client Access Virtual Directory wizard to reset one or more Client Access server virtual directories. The new wizard makes it easier to reset a Client Access server virtual directory. One reason that you might want to reset a Client Access server virtual directory is to resolve an issue related to a damaged file on a virtual directory. In addition to resetting virtual directories, the wizard creates a log file that includes the settings for each virtual directory that you choose to reset. For more information, see Reset Client Access Virtual Directories.

Client Throttling Policies

You can use client throttling policies to help you manage performance of your Client Access servers. Consider the following changes as you use client throttling policies to manage performance when running Exchange 2010 SP1.

In Exchange 2010 RTM, only the policies to limit the number of concurrent client connections were enabled by default. In Exchange 2010 SP1, all client throttling policies are enabled by default. In Exchange 2010 RTM, when the thresholds defined on a latency-based client throttling policy parameter such as EWSPercentTimeInCAS were exceeded, Exchange would cause the transactions and connections to fail. In Exchange 2010 SP1, exceeding the thresholds defined on a latency-based throttling policy parameter will not cause a failure. Instead, Exchange will delay transactions and connections until the transaction rate is within the policy limits. Such transaction and connection delays will usually not be apparent to end users. Client throttling policy parameters with a hard quota limits such as EWSMaxSubscriptions will cause a failure when exceeded. As an administrator, you can monitor the impact of your performance policies and make adjustments as needed. Two new cmdlets, Get-ThrottlingPolicyAssociation and Set-ThrottlingPolicyAssociation, help you manage and apply client throttling polices to specific objects. For more information, see Understanding Client Throttling Policies and Managing Performance with Client Throttling Policies.

Improvements in Transport Functionality

The following is a list of new Transport functionality in Exchange 2010 SP1:

MailTips access control over organizational relationships Enhanced monitoring and troubleshooting features for MailTips Enhanced monitoring and troubleshooting features for message tracking Message throttling enhancements Shadow redundancy promotion SMTP failover and load balancing improvements Support for extended protection on SMTP connections Send connector changes to reduce NDRs over well-defined connections For more information and details about these changes, see New Transport Functionality in Exchange 2010 SP1.

Permissions Functionality
The following is a brief description of new permissions features and enhancements in Exchange 2010 SP1:

Database scope support With database scopes, you can control which databases mailboxes can be created for a given set of administrators and also control which databases they can manage. For more information about database scopes, see Understanding Management Role Scopes. Active Directory split permissions Active Directory split permissions enable you to completely separate the administrative capabilities of Exchange administrators from your Active Directory administrators. The ability to create and remove Active Directory users and groups and manage non-Exchange attributes of Active Directory objects by Exchange administrators and servers has been removed in Exchange 2010 SP1. For more information about Active Directory split permissions, see Understanding Split Permissions. Improved user interface You can now create and manage management role groups and management role assignment policies in the Exchange Control Panel (ECP). This includes adding and removing management roles to role groups and role assignment policies, adding and removing members to and from role groups, and assigning users to role assignment policies. For more information about how to manage role groups and role assignment policies, see the following topics: Managing Administrator and Specialist Users Managing End Users

Exchange Store and Mailbox Database Functionality

The following is a list of new store and mailbox database functionality in Exchange 2010 SP1:

With the New-MailboxRepairRequest cmdlet, you can detect and repair mailbox and database corruption issues. Store limits were increased for administrative access. The Database Log Growth Troubleshooter (Troubleshoot-DatabaseSpace.ps1) is a new script that allows you to control excessive log growth of mailbox databases. Public Folders client permissions support was added to the Exchange Management Console (EMC). For more information and details about each of these features, see New Exchange Core Store Functionality in Exchange 2010 SP1.

Mailbox and Recipients Functionality

The following is a list of new mailbox and recipient functionality included in Exchange 2010 SP1:

In Outlook 2010 and Outlook 2007, Autodiscover automatically loads any mailbox for which a user has been granted full access permission. Users cant control or disable this behavior. Calendar Repair Assistant supports more scenarios than were available in Exchange 2010 RTM. Mailbox Assistants are now all throttle-based (changed from time-based in Exchange 2010 RTM). Internet calendar publishing allows users in your Exchange organization to share their Outlook calendars with a broad Internet audience. Importing and exporting .pst files now uses the Mailbox Replication service and doesn't require Outlook. Hierarchical address book support allows you to create and configure your address lists and offline address books in a hierarchical view. Distribution group naming policies allow you to configure string text that will be appended or prepended to a distribution group's name when it's created. Soft-delete of mailboxes after move completion. For more information and details about these features, see New Mailbox and Recipient Functionality in Exchange 2010 SP1.

High Availability and Site Resilience Functionality

The following is a list of new high availability and site resilience functionality included in Exchange 2010 SP1:

Continuous replication - block mode Active mailbox database redistribution Enhanced datacenter activation coordination mode support New and enhanced management and monitoring scripts Exchange Management Console user interface enhancements Improvements in failover performance For more information about these features, see New High Availability and Site Resilience Functionality in Exchange 2010 SP1.

Messaging Policy and Compliance Functionality

The following is a list of new messaging policy and compliance functionality included in Exchange 2010 SP1:

Provision personal archive on a different mailbox database Import historical mailbox data to personal archive Delegate access to personal archive New retention policy user interface Opt-in personal tags Multi-Mailbox Search preview Annotations in Multi-Mailbox Search Multi-Mailbox Search data de-duplication WebReady Document Viewing of IRM-protected messages in Outlook Web App IRM in Exchange ActiveSync for protocol-level IRM IRM logging Mailbox audit logging For more information and details about each of these features, see New Messaging Policy and Compliance Functionality in Exchange 2010 SP1.

Unified Messaging Server Role Improvements

The Unified Messaging server role has been improved and has added new features in Exchange 2010 SP1. To use some of these features, you must correctly deploy Microsoft Lync Server 2010 in your environment. The following is an overview of all the new features in Exchange 2010 Unified Messaging:

UM reporting The reports for Call Statistics and User Call Logs found in the Exchange Management Console are displayed in the Exchange Control Panel. UM management in the Exchange Control Panel You can usethe ECP to manage UM components in a cross-premises environment. Cross-Forest UM-enabled mailbox migration In Exchange 2010 SP1, you can use the New-MoveRequest cmdlet with the Mailbox Replication Service (MRS) to move a UM-enabled mailbox within a local forest and multiple forests in an enterprise. Outlook Voice Access improvements Outlook Voice Access users can log on to their Exchange 2010 mailbox and choose the order to listen to unread voice mail messages, from the oldest message first or the newest message first. Caller Name Display support Exchange 2010 SP1 includes support for enhanced caller ID resolution for displaying names for voice mails from unresolved numbers using Caller Name Display (CND).

Test-ExchangeUMCallFlow cmdlet With this Exchange 2010 SP1 cmdlet, you can test UM connectivity and call flow. New UM Dial Plan wizard An additional page has been added to the New UM Dial Plan wizard that allows you to add a UM server to the dial plan. Lync Server 2010 Support Migrating SIP URI dial plans and Message Waiting Indicator (MWI) notifications in a cross-premises environment has been added. Secondary UM dial plan support You can add a secondary UM dial plan for a UM-enabled user. UM language packs added New UM language packs are now available in Exchange 2010 SP1. In addition, the Spanish (Spain) (es-ES) UM language pack available for Exchange 2010 SP1 now includes Voice Mail Preview, a feature that wasnt available in the Exchange 2010 RTM release of that language pack. Call answering rules improvements There are three updates to Call Answering Rules for UM-enabled users in SP1. Unified Communications Managed API/speech platform improvements Beginning with Exchange 2010 SP1, the UM server relies on Unified Communications Managed API v. 2.0 (UCMA) for its underlying SIP signaling and speech processing. UM auto attendant update In Exchange 2010 SP1, a UM auto attendant will play only the holiday greeting on a holiday. For more information and details about each of these features, see New Unified Messaging Functionality and Voice Mail Features in Exchange 2010 SP1.

Audit Logging Improvements

Exchange 2010 SP1 provides improvements in functionality related to administrator audit logging and new functionality for mailbox audit logging:

Improvements in administrator audit logging Exchange 2010 enhances the administrator audit logging functionality by providing you with the ability to perform searches of the admin audit log using the Exchange Management Shell. You can search on cmdlet and parameter names, date, the user who ran the command, and more. The results generated by your search can be displayed on the screen or e-mailed to a recipient you specify and viewed as an XML file. And, because all the administrative interfaces run Shell cmdlets in the background, the actions that occur in all the interfaces can be logged. For more information, see Overview of Administrator Audit Logging. New mailbox audit logging Exchange 2010 SP1 introduces new mailbox audit logging functionality to allow you to track mailbox access by administrators, delegates, and mailbox owners, and actions taken on mailbox items such as moving or deleting a message, using SendAs or SendOnBehalf rights to send messages, and accessing a mailbox folder or a message. You can use the ECP to generate a report of non-owner mailbox access and use the Shell to search mailbox audit logs. For more information, see Understanding Mailbox Audit Logging. The Exchange Control Panel also provides several reports which are generated based on the audit logs in Exchange 2010 SP1.

Support for Hybrid Deployments with Exchange Online

Exchange 2010 SP1 includes the following functionality that supports hybrid deployments with Exchange Online:

Migration of UM-enabled mailboxes The New-MoveRequest cmdlet can be used with the Microsoft Exchange Mailbox Replication service (MRS) to move a UM-enabled mailbox within a hybrid deployment. IRM support for hybrid deployments IRM is fully supported for hybrid deployments. The tenant administrator can export the trusted publishing domain from the on-premises Active Directory Rights Management Services (AD RMS) server and import it to the cloud-based service. This functionality allows IRM-protected messages to be decrypted in the cloud, and cloud mailbox users to send IRM-protected messages that on-premises mailbox users can decrypt and access. Remote Mailboxes A new set of SP1 cmdlets allow you to create and manage a mail-enabled user in the on-premises Active Directory site and at the same time create and manage the associated mailbox in the cloud-based service. The cmdlets are: New-RemoteMailbox Set-RemoteMailbox Get-RemoteMailbox Enable-RemoteMailbox Disable-RemoteMailbox Remove-RemoteMailbox Transport Updated features in Transport help ensure that message flow remains protected between users regardless of where their mailboxes are located. Enhanced Transport features such as MailTips, delivery reports, and message moderation also support this deployment scenario.

Support for Multi-Tenancy

With Exchange 2010 SP1 built-in multi-tenant support, service providers that use Microsoft Service Provider Licensing Agreement (SPLA) no longer need a solution such as Microsoft Hosted Messaging and Collaboration version 4.5 to host multiple organizations. Multi-tenant support in Exchange 2010 SP1 provides the core feature set of Microsoft Exchange that can be deployed to multiple customers in a single installation, and it also provides ease of management and flexibility of provided features to end-users. In addition to including most of the features and functionality available in Exchange 2010 SP1 Enterprise deployments, the multi-tenant solution available for Exchange 2010 SP1 also includes features and functionality that allow you to create and manage tenant organizations. For more information, see Multi-Tenant Support.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

New Deployment Functionality in Exchange 2010 SP1

Exchange 2010 Applies to: Exchange Server 2010 SP1 Topic Last Modified: 2010-07-21 This topic provides a brief overview of the new functionality available for deploying Microsoft Exchange 2010 Service Pack 1 (SP1). During an Exchange 2010 SP1 installation, you can now select a new option to install the required Windows roles and features for each selected Exchange 2010 SP1 server role.

Exchange 2010 SP1 Install

Exchange 2010 SP1 Setup has been improved to allow you to install the required Windows roles and features. If you select the option to install Windows roles and features, progress is shown and the appropriate roles and features are installed. If a reboot is required, you will have to reboot the server and launch Setup again. When Setup is launched again, Setup will resume where it left off. If you dont select the option to install Windows roles and features, you can manually install the Windows roles and features and continue Setup after the prerequisites are met.

Unattended Install
You can now select the /InstallWindowsComponents parameter during an unattended install of Exchange 2010 SP1. If you select the option to install Windows roles and features, progress is shown and the appropriate roles and features are installed. If a reboot is required, you will have to reboot the server and launch Setup.com again with the /InstallWindowsComponents parameter. If the Windows roles and features were correctly installed, Setup.com will continue.

Exchange 2010 RTM to Exchange 2010 SP1 Upgrade

When you run Exchange 2010 unattended install to upgrade from the release to manufacturing (RTM) version of Exchange 2010 to Exchange 2010 SP1, you can use the Setup.com /m:upgrade /installwindowscomponents command. If a reboot is required, you will have to reboot the server and again launch Setup.com /m:upgrade with the /InstallWindowsComponents parameter. If the Windows roles and features were correctly installed, Setup.com will continue.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

New Mailbox and Recipient Functionality in Exchange 2010 SP1

Exchange 2010 Applies to: Exchange Server 2010 SP1 Topic Last Modified: 2011-04-28 Microsoft Exchange Server 2010 Service Pack 1 (SP1) provides new functionality for Mailbox servers, mailboxes, and recipients. New functionality is available for the following:

Mailbox full access permission and Outlook Automapping Group naming policies Mailbox data Move requests Archive mailboxes Hierarchical address books Mailbox folder permissions Internet calendar publishing Calendar Repair Assistant Mailbox Assistants service troubleshooter

Mailbox Full Access Permission and Outlook Automapping

In Microsoft Office Outlook 2010 and Outlook 2007, Autodiscover automatically maps to any mailbox for which a user has full access permissions. After an administrator grants full access permission for a user to access another user's mailbox or if the user has full access permission to a shared mailbox, Autodiscover automatically loads all mailboxes for which the user has full access permissions. This behavior may cause performance issues when Outlook starts if the user has a large number of mailboxes to which they have full access. For example, in some organizations, Exchange administrators have full access to all users' mailboxes in their organization. If that is the case, Outlook attempts to open all mailboxes in the organization. Note: Users cant control or disable this behavior. For more information, see Allow Mailbox Access and Manage Full Access Permissions.

Group Naming Policies

A group naming policy is a template that you can apply to the name of distribution groups created in the organization. You can enforce the application of a prefix, a suffix, or both to distribution groups. You can also block specific words from being used in distribution group names. For more information, see Create a Distribution Group Naming Policy.

Mailbox Data
Importing and exporting mailbox data has been improved so that you can import or export .pst files in an asynchronous process using the Microsoft Exchange Mailbox Replication service. The following cmdlets have been added in Exchange 2010 SP1 to support this feature:

Get-MailboxExportRequest Get-MailboxExportRequestStatistics New-MailboxExportRequest Remove-MailboxExportRequest Resume-MailboxExportRequest Set-MailboxExportRequest Suspend-MailboxExportRequest Get-MailboxImportRequest Get-MailboxImportRequestStatistics New-MailboxImportRequest Remove-MailboxImportRequest Resume-MailboxImportRequest Set-MailboxImportRequest Suspend-MailboxImportRequest For more information, see Understanding Mailbox Import and Export Requests.

Move Requests
New functionality in Exchange 2010 SP1 for move requests includes the following:

In the release to manufacturing (RTM) version of Exchange 2010, when a mailbox move completed, the mailbox on the source database was deleted and wasn't recoverable. If there was a Mailbox server failover on the target database, the mailbox move was interrupted, and data loss for the in-transit mailbox could occur. Exchange 2010 SP1 now soft-deletes the mailbox on the source database, so you can recover the mailbox in the event of a Mailbox server failover or data loss.

You can restore a soft-deleted mailbox by using the MailboxRestoreRequest cmdlets set. These soft-deleted mailboxes are visible when running the Get-MailboxStatistics cmdlet against a database and are identifiable by the property DisconnectReason with a value of SoftDeleted. The soft-deleted mailboxes will be retained in the source database until either the deleted mailbox retention period expires or the mailbox is purged by using the Remove-StoreMailbox cmdlet. If you're performing mailbox moves to reduce the amount of space being used in a database, you must also perform the additional step of purging the soft-deleted mailboxes. Soft-deleted mailboxes can't be reconnected. Note: You can't view soft-deleted mailboxes by using the Get-MailboxStatistics cmdlet in Exchange versions earlier than Exchange 2010 SP1. The MoveRequest cmdlet set has been updated to support moving archives to a separate database. For more information, see Understanding Move Requests.

Archive Mailboxes
You can now have a user's primary mailbox and archive mailbox on separate databases. For more information, see Understanding Personal Archives.

Hierarchical Address Books

With hierarchical address book support, you can create and configure your address lists and offline address books (OABs) in a hierarchical view. For more information, see Understanding Hierarchical Address Books.

Mailbox Folder Permissions

A new cmdlet has been added that you can use to modify the mailbox folder permissions. The Set-MailboxFolderPermission cmdlet updates folder-level permissions for all folders within a user's mailbox. The cmdlet differs from the Add-MailboxFolderPermission cmdlet in that it edits an existing permission entry.

Internet Calendar Publishing

In Exchange 2010 RTM, sharing user calendar information required a federation trust and an organization relationship or sharing policy with another federated organization. Exchange 2010 SP1 introduces Internet calendar publishing so that users in your Exchange organization can share their calendars with anyone that has access to the Internet, and not just with other recipients in other federated Exchange organizations. Highlights of Internet calendar publishing include:

Federation configuration isn't necessary for your Exchange organization. Internet users don't need any type of authentication credentials to access user calendars (for example, Exchange or Windows Live). Users can invite their friends, family members, or business partners to view their calendar information by providing a link to their published calendar. Exchange administrators can control which users can publish their calendars and what can be shared, both organization-wide and on a per-user basis. Internet users can access calendar information without having to use a specific mail client; only an Internet browser is necessary. For more information about sharing policy and calendar publishing, see the following topics:

Understanding Federated Delegation Configure Sharing Policy Properties Create a Sharing Policy You can use the Test-CalendarConnectivity cmdlet to verify that Internet calendar sharing is enabled and working properly. The Calendar virtual directory is a subdirectory of the Exchange Outlook Web App virtual directory.

Calendar Repair Assistant

The Calendar Repair Assistant (CRA), which was introduced in Exchange 2010 RTM, is a mailbox assistant that runs within the Microsoft Exchange Mailbox Assistants service on servers running Exchange 2010 with the Mailbox server role installed. CRA automatically detects and corrects inconsistencies that occur for single and recurring meeting items for mailboxes homed on that Mailbox server so that recipients won't miss meeting announcements or have unreliable meeting information. In Exchange 2010 SP1, the Calendar Repair Assistant checks for and detects the following new scenarios:

The attendee's calendar is missing an occurrence or an exception of a meeting. The attendee's start or end time doesn't match the organizer's start or end time, including time zone inconsistencies. The attendee's meeting location is different from the organizer's meeting location. The meeting organizer's calendar is missing an item. The attendee's recurrence pattern of a meeting series is different from the organizer's recurrence pattern. For more information, see Understanding Calendar Repair.

Mailbox Assistants Service Troubleshooter

The Test-AssistantHealth cmdlet is a new cmdlet that can help you troubleshoot the health of the Microsoft Exchange Mailbox Assistants service (MSExchangeMailboxAssistants). Use the Test-AssistantHealth cmdlet to verify that the Mailbox Assistants service is healthy, to recover from health issues, and to report the status of the diagnosis or recovery action.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

New High Availability and Site Resilience Functionality in Exchange 2010 SP1
Exchange 2010 Applies to: Exchange Server 2010 SP1 Topic Last Modified: 2012-04-25 Microsoft Exchange Server 2010 Service Pack 1 (SP1) includes new features, as well as enhancements to features introduced in the release to manufacturing (RTM) version of Exchange 2010. The new and improved features extend the scenarios in which you can achieve data and service availability for your Exchange 2010 environment. The following new features for high availability and improvements to existing high availability features are available in Exchange 2010 SP1:

Continuous replication - block mode Active mailbox database redistribution Enhanced datacenter activation coordination mode support New and enhanced management and monitoring scripts Exchange Management Console user interface enhancements Improvements in failover performance Extensible Storage Engine recovery on hung I/O These features are discussed in greater detail below.

Continuous Replication - Block Mode

In the RTM version of Exchange 2010 and in all versions of Exchange Server 2007, continuous replication operates by shipping copies of the log files generated by the active database copy to the passive database copies. Beginning with Exchange 2010 SP1, this form of continuous replication is known as continuous replication - file mode. Exchange 2010 SP1 also introduces a new form of continuous replication known as continuous replication - block mode. In block mode, as each update is written to the active database copy's active log buffer, it's also shipped to a log buffer on each of the passive mailbox copies. When the log buffer is full, each database copy builds, inspects, and creates the next log file in the generation sequence. If a failure affects the active copy, the passive copies will have been updated with most or all of the latest updates. The active copy doesn't wait for replication to complete to preclude replication issues from affecting the client experience. Continuous replication - block mode is only active when continuous replication is up-to-date in file mode. The transition into and out of block mode is performed automatically by the log copier. Block mode dramatically reduces the latency between the time a change is made on the active copy and when the change is replicated to passive copies. In addition to replicating individual log file writes, block mode also changes the activation process for a passive copy. If a copy is in block mode when a failure occurs, the system uses whatever partial log content is available during the activation process. This eliminates the current log file on the active copy from being a single point of failure.

Active Mailbox Database Redistribution

Exchange 2010 SP1 includes a script called RedistributeActiveDatabases.ps1 that can be periodically run by administrators to balance the distribution of active database copies across a database availability group (DAG) based on administrator-configured activation preference. In addition, copy distribution awareness has been added to the Active Manager best copy selection process. Specifically, the first pass of best copy selection for lossless switchovers now sorts the possible targets by preference instead of least loss.

Enhanced Datacenter Activation Coordination Mode Support

Exchange 2010 RTM includes a configuration mode for DAG site resilience support called Datacenter Activation Coordination (DAC) mode. In DAC mode, Exchange cmdlets can be used to perform a data center switchover. In the RTM version, DAC mode is limited to DAGs with at least three members that have at least two or more members in the primary data center. In Exchange 2010 SP1, DAC mode has been extended to support two-member DAGs that have each member in a separate data center. DAC mode support for twomember DAGs uses the witness server to provide additional arbitration. In addition, DAC mode has been extended to support DAGs that have all members deployed in a single Active Directory site, including single Active Directory sites that have been extended to multiple locations.

New and Enhanced Management and Monitoring Scripts

Exchange 2010 SP1 includes several new and enhanced scripts that greatly improve the management and monitoring experience:

CheckDatabaseRedundancy.ps1 (new) You can use this script to check the redundancy of replicated databases, and it will generate events if database resiliency is found to be in a compromised state (for example, there's only one healthy copy of a replicated database). The script is accompanied by a Microsoft System Center Operations Manager 2007 management pack change that can be used to monitor databases without redundancy, which is particularly useful in environments without RAID. StartDagServerMaintenance.ps1 and StopDagServerMaintenance.ps1 (new) You can use StartDagServerMaintenance.ps1 to take a DAG member out of service for maintenance. It will move active databases off of the server and block databases from moving to that server. It will also make sure all critical DAG support functionality (for example, the Primary Active Manager PAM role) that might be on the server is moved to another server, and blocked from moving back to the server. Another script, StopDagServerMaintenance.ps1, is provided to complete the operation and remove the blocks. CollectOverMetrics.ps1 (enhanced) You can use this script to collect switchover and failover data. This script has been enhanced in Exchange 2010 SP1 to include metrics for continuous replication - block mode, and more details from the replication and replay pipeline. In addition, it also features enhanced reporting. CollectReplicationMetrics.ps1 (enhanced) This script is an active form of monitoring because it collects metrics related to continuous replication in real time

while the script is running. The script supports parameters that enable you to customize the script's behavior and output.

Enhanced Exchange Management Console User Interface

Exchange 2010 SP1 includes Exchange Management Console (EMC) enhancements for managing DAGs. For example, the EMC now includes support for managing IP addresses and alternate witness server settings for DAGs. It's no longer necessary to use the Exchange Management Shell to configure these settings.

Improved Failover Performance

Exchange 2010 SP1 includes changes to improve failover and switchover performance and behavior. In the RTM version of Exchange 2010, when either a failover or a switchover occurs, the passive copy being activated immediately stops replaying log files that were copied to that passive copy. The active copy is then dismounted (if it's not already), and any remaining log files are copied to the passive copy being activated. Assuming that any missing data is within the automatic database mount dial setting, the passive copy is made the new active copy and the database is mounted in a dirty shutdown state. At this point, all log files that were copied to the previously passive (and now active) copy will be replayed to make the database consistent. In Exchange 2010 SP1, when either a failover or a switchover occurs, the Microsoft Exchange Replication service on the passive copy being activated continues to replay log files that have been copied to the passive copy until the last log file generated by the active copy is copied to it. This enables a mount operation to be performed against a database that is in a nearly consistent state. Other performance-enhancing changes involve time-outs and other algorithmic details to improve failover performance as well as I/O performance after failovers.

Extensible Storage Engine Recovery on Hung I/O

Exchange 2010 SP1 includes new recovery logic that makes use of the built-in Windows bugcheck behavior when certain conditions occur. Specifically, Extensible Storage Engine (ESE) has been updated to detect when I/O is hung and to take corrective action to automatically recover the server. ESE maintains an I/O monitoring thread that detects when an I/O has been outstanding for a specific period of time. By default, if an I/O for a database is outstanding for more than one minute, ESE logs an event. If a database has an I/O outstanding for greater than 4 minutes, ESE logs a specific failure event, if its possible to do so. ESE event 507, 508, 509, or 510 may or may not be logged, depending on the nature of the hung I/O. If the problem is such that the operating system volume is affected or the ability to write to the event log is affected, the events arent logged. If the events are logged, the Microsoft Exchange Replication service MSExchangeRepl.exe intentionally terminates the wininit.exe process to cause a bugcheck of Windows. In some cases, the entire storage stack may be affected by the hang, making it impossible to write failure events to the crimson channel or any other area of the Windows Event Log. ESE also monitors the crimson channel by verifying that the event log can be written to. If writing to the event log fails for a long period of time, MSExchangeRepl intentionally causes a bugcheck of Windows by terminating wininit.exe. When the operating system I/O is hung, the system is obviously unable to write any ESE events to the event log. Note: Applications and Services logs are a new category of event logs in Windows Server 2008. These logs store events from a single application or component rather than events that might have system-wide impact. This new category of event logs is referred to as an application's crimson channel. For more information, see Monitoring High Availability and Site Resilience This new bugcheck-based recovery feature in Exchange 2010 SP1 is designed to make recovery from hung I/O or a hung controller fast, rather than re-trying or waiting until the storage stack raises an error that causes failover. When the bugcheck occurs, the error code reads as follows:

CRITICAL_OBJECT_TERMINATION (f4) A process or thread crucial to system operation has unexpectedly exited or been terminated. Warning: The presence of this bugcheck error code doesnt necessarily mean that Exchange was the cause of the error. Any termination of wininit.exe, including one performed by an administrator using Task Manager or some other task management tool, will cause the same bugcheck error code.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

New Messaging Policy and Compliance Functionality in Exchange 2010 SP1

Exchange 2010 [This topic is in progress.] Applies to: Exchange Server 2010 SP1 Topic Last Modified: 2011-01-26 Microsoft Exchange Server 2010 Service Pack 1 (SP1) includes new features, as well as enhancements to features that were introduced in the release to manufacturing (RTM) version of Exchange 2010. This topic provides a brief description of new functionality for existing features and information about new features related to messaging policy and compliance in Exchange 2010 SP1.

Personal Archive Functionality

Personal archive functionality in Exchange 2010 SP1 includes the following:

Provision personal archive on a different mailbox database You can provision a user's personal archive on a different mailbox database than the one where the user's primary mailbox resides. This capability allows you to implement a tiered storage topology. Import historical mailbox data to archive You can import historical mailbox data from .pst files directly to the user's personal archive using the NewMailboxImportRequest cmdlet in the Shell. Data from .pst files can also be imported to the user's primary mailbox, and both the personal archive and the primary mailbox can be exported to .pst files using the New-MailboxExportRequest cmdlet. Delegate access to archive Delegates can access the delegating user's archive mailbox using Microsoft Office Outlook 2010, in addition to the primary mailbox. For more information, see Understanding Personal Archives.

Messaging Records Management Functionality

Messaging records management functionality in Exchange 2010 SP1 includes the following:

New retention policy management features in EMC You can use the New Retention Policy Tag and New Retention Policy wizards in the Exchange Management Console (EMC) to manage retention tags and retention policies. Support for Notes default folder You can also create retention policy tags for the Notes default folder. Default retention and archive policy The default archive policy and retention policy contains retention tags that move messages to the archive and remove messages from the mailbox after a certain period. The policy is automatically applied to a mailbox user when you provision a personal archive for the user. Opt-in personal tags Users with a retention policy assigned can use the Exchange Control Panel (ECP) to select personal tags not included in their retention policy. Users can then apply these personal tags to mailbox items and custom folders. For more information, see Understanding Retention Tags and Retention Policies.

Multi-Mailbox Search Functionality

Multi-Mailbox Search functionality in Exchange 2010 SP1 includes the following:

Multi-Mailbox Search preview In Exchange 2010 SP1, discovery managers (that is, users who are members of the Discovery Management management role group) can get an estimate of the number of items returned by a discovery search before the items are copied to the selected discovery mailbox. This functionality allows discovery managers to view the number of hits the specified keywords return, and then modify the search query, if required, before messages returned by the search are copied to the discovery mailbox. Annotations Discovery managers can also add annotations to messages returned by the discovery search. Data de-duplication Multi-Mailbox Search includes the optional data de-duplication feature. When selected, Multi-Mailbox Search copies only a single instance of a message returned across multiple folders within the same mailbox, or across different mailboxes. For more information, see Understanding Multi-Mailbox Search.

Information Rights Management Functionality

Information Rights Management (IRM) functionality in Exchange 2010 SP1 includes the following:

WebReady Document Viewing of IRM-protected attachments In Exchange 2010 SP1, IRM in Microsoft Office Outlook Web App supports WebReady Document Viewing of supported IRM-protected attachments, allowing users to view IRM-protected attachments without having to download them. Users can preview IRM-protected documents on computers that don't have Microsoft Office installed. Along with the cross-browser and cross-platform support in Outlook Web App, this functionality extends the reach of IRM to various browsers and operating systems. For more information, see Understanding Information Rights Management in Outlook Web App. IRM in Exchange ActiveSync IRM in Exchange ActiveSync allows users with supported devices to access IRM-protected messages without first having to activate the device for IRM by tethering the device to a computer. For more information, see Understanding Information Rights Management in Exchange ActiveSync. Cross-organization support Exchange 2010 SP1 IRM features are supported in cross-organization topologies for easier collaboration between two organizations via OWA. IRM logging In Exchange 2010 SP1, you can enable logging of IRM features on the Mailbox, Hub Transport, Client Access, and Unified Messaging server roles. IRM logs contain detailed transaction and error information, allowing administrators to easily monitor and troubleshoot IRM features. For more information, see Understanding Information Rights Management Logging. Discovery Manager access to IRM-protected messages in a Discovery mailbox In Exchange 2010 SP1, you can configure IRM to allow members of the

Discovery Management role group to access IRM-protected messages returned by discovery search. For more information, see Understanding Information Rights Management.

Mailbox Audit Logging Functionality

Exchange 2010 SP1 includes new logging functionality that allows you to enable logging of mailbox access. Mailbox audit logging enables you to log access to a mailbox by administrators, delegates, and mailbox owners. Actions taken on mailbox items such as access to a message or a folder, copying, and deletion of a message can be logged. You can search mailbox audit logs for a mailbox, and also generate reports of non-owner access to a mailbox from the Exchange Control Panel. For more information, see Understanding Mailbox Audit Logging.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

New Unified Messaging Functionality and Voice Mail Features in Exchange 2010 SP1
Exchange 2010 Applies to: Exchange Server 2010 SP1 Topic Last Modified: 2012-10-30 The Unified Messaging server role has been improved in Microsoft Exchange Server 2010 Service Pack 1 (SP1), and new features have been added. To use some of these new features, you must correctly deploy Microsoft Office Communications Server 2007 R2 or Microsoft Lync Server 2010 (the next generation of Office Communications Server) in your environment. This topic discusses the new and improved features that are added when you install Exchange 2010 SP1.

UM Features Found in Exchange 2010 SP1

The following is a list of the new features in Exchange 2010 Unified Messaging (UM) and a description of the features:

UM management in the Exchange Control Panel The UM management user interface in the Exchange Control Panel makes it possible to manage all components of Unified Messaging in a Web browser. You can create UM dial plans, UM mailbox policies, UM IP gateways, and UM auto attendants, and enable users for Unified Messaging. This feature is available to tenant administrators (also called specialists) and to administrators in cross-premises Exchange environments. For details, see Managing Administrator and Specialist Users. Administrators can also use the Exchange Control Panel to manage some on-premises and cross-premises tasks. The following is a list of some of the additional administrative features available in the Exchange Control Panel for all server roles, including: Text messaging integration Voice messaging integration Multiple mailbox search Additional proxy addresses for mailboxes Moderation and approval for distribution list submission In addition, end users can perform common administrative tasks in the Exchange Control Panel without having to call their helpdesk. This helps them to be more productive and reduces support costs. Although the Exchange Control Panel is available to Exchange administrators for managing Unified Messaging in a cross-premises environment, as a best practice, the Exchange Management Console and the Exchange Management Shell are the preferred tools for creating and configuring UM components. UM reporting The UM reporting features added in Exchange 2010 SP1 include call summaries and statistics and call details for UM-enabled users. These reports are displayed in the Exchange Control Panel. You can access Unified Messaging statistic reports by using Call Statistics in EMC and access call logs by using User Call Logs, also in the EMC. Both tools are located under the Toolbox node. They provide aggregated statistical information about calls for UM servers and calls for UM-enabled users. To support the UM reporting tools in the EMC, the following cmdlets have been added for SP1: Get-UMCallSummaryReport Get-UMCallDataRecord In the EMC toolbox, Call Statistics provides aggregated statistical information about calls forwarded to or placed by UM servers and can be used by administrators interested in overall statistics for the Exchange 2010 Unified Messaging servers in their organization. The results of the call statistics reports you request in the EMC are displayed in the Exchange Control Panel user interface. They can be filtered to show call statistics by month or by day for the past 90 days or since UM was deployed in your organization. You can then filter these results by UM dial plan and UM IP gateway within your organization. Call statistics reports display: The total number of calls organized by type of call (for example, missed calls, Outlook Voice Access calls, or fax calls). Whether the call was accepted or rejected. The average audio quality. The day or the month covered in the report, or all calls. You can export the call logs to a Microsoft Office Excel template, or copy the call statistics information to the Clipboard so that it can be pasted into another application. You can use the Audio Quality Details button to display more specific information about the call, including: Date UM dial plan UM IP gateway Type of audio codec NMOS NMOS degradation Jitter Pack loss Round trip time Burst Loss Duration Number of calls sampled For more information about the specific information that's available for calls, see Using Unified Messaging Tools. You can use User Call Logs in the EMC toolbox to view the call statistics for a selected UM-enabled user. The report is displayed in the Exchange Control Panel and is useful in helpdesk-type situations where you have to gather information about specific calls for a UM-enabled user to assist them in diagnosing and fixing issues. After you click Select a user and specify the user, the following information will be displayed for calls of the UM-enabled user you selected: Date and time Duration of the call Type of call The calling number The called number The UM IP gateway Audio quality You can copy the user's call statistics to the Clipboard and then paste them into another application. You can use the Audio Quality Details button to display more specific information about the call including: Date UM dial plan UM IP gateway Type of audio codec NMOS NMOS degradation Jitter Pack loss

Round trip time Burst Loss Duration For more information about the specific information that's available for calls, see Using Unified Messaging Tools. Cross-forest migration of UM-enabled mailboxes Before Exchange 2010 SP1, there wasn't a way to efficiently move UM-enabled mailboxes from a source Exchange 2010 forest to a target Exchange 2010 forest when performing any kind of Enterprise cross-forest migration. The only way to do this was to first disable the mailbox for UM in the source forest, and then move the mailbox to the target forest. If you were moving an Exchange Server 2007 mailbox, you would use the Move-Mailbox cmdlet. If you were moving an Exchange 2010 mailbox, you would use the New-MoveRequest cmdlet. After you moved the mailbox to the target forest, you would then enable the mailbox for UM. Following this process created several issues. The process took a long time to complete, the user's voice mail was taken offline, and the UM-enabled user's PIN would be reset, which forced the user to set up a new PIN for Outlook Voice Access. In SP1, the New-MoveRequest cmdlet is used with the Mailbox Replication service (MRS) to move a UM-enabled mailbox within a forest, or between multiple forests in on-premises deployments. Using the New-MoveRequest cmdlet with the MRS to move the UM-enabled mailbox lets you speed up the process, leaves the user's voice mail online, and doesn't require an Outlook Voice Access user to reset their PIN. The process for moving UM-enabled mailboxes works as follows in Exchange 2010 SP1: In your source forest, you have UM-enabled mailboxes that are associated with a UM mailbox policy in the same source forest. You then: 1. Identify the target UM mailbox policy that you want to associate with the UM-enabled mailboxes after you have moved them to the target forest. 2. Use the Set-UMMailboxPolicy cmdlet and specify the name of the UM mailbox policy in the source forest using the SourceForestPolicyNames parameter on the UM mailbox policy in the target forest. 3. Start moving the UM-enabled mailboxes to the target forest without disabling them. As you migrate the mailboxes, the mailboxes in the source forest will continue to receive voice mail messages and e-mail messages. 4. Directly after the migration of the UM-enabled mailbox, the MRS will automatically disable the mailboxes in the source forest. 5. In addition to the UM mailbox policy in the target forest, the MRS must have the extension numbers that are already assigned to the users whose mailboxes were moved. The MRS will use the extension numbers to locate the matching UM mailbox policy in the target forest by searching the SourceForestPolicyNames parameter on the UM mailbox policy. After the extension numbers and the name of the UM mailbox policy are found, MRS will UM-enable the mailboxes in the target forest. Note: The MRS uses RPC over HTTP for cross-forest migrations and RPC over TCP for intra-forest migrations. Outlook Voice Access improvements In Exchange 2007 and the RTM version of Exchange 2010, UM-enabled users can listen to their voice messages using Outlook Voice Access. By default, a Unified Messaging server retrieves and lists voice messages by date in descending order. For example, if two voice messages are sent, one at 10:00 a.m. and another at 1:00 p.m. the same day, UM will first play the voice message left at 1:00 p.m. and then play the voice message that was left earlier. Now, in SP1, when Outlook Voice Access users sign in to their Exchange 2010 mailbox, they can chose the play order for unread voice mail messages, either oldest first or newest first. Users can configure this order by using the Voice Mail tab in Outlook Web App, by managing their voice mail settings in Microsoft Outlook 2010, and by using the menu system in Outlook Voice Access. Caller Name Display Caller ID resolution has been enhanced in SP1. Names can now be displayed for voice messages from unresolved numbers using Caller Name Display. With Caller Name Display, IP gateways or IP PBXs pass caller name information as part of the SIP FROM header. In some countries, including the United States, the public telephone networks can supply the name of the registered subscriber for the calling phone number. This is administered by the telephone service provider that provides service to the caller. Phones with alphanumeric displays will show the registered name for the caller when the call offers it. With Caller Name Display, instead of displaying Voice Mail from 4255551234, the Unified Messaging server can send a voice message that displays Voice Mail from Tony Smith. New UM Dial Plan Wizard and Set-UMServer When you deployed Unified Messaging in Exchange 2010 RTM, you had to add or associate a UM server with a UM dial plan after you created the dial plan. In SP1, you can add or associate a UM server with a UM dial plan when you create a UM dial plan. An additional page has been added to the New UM Dial Plan wizard that lets you add a UM server to the dial plan.

Microsoft Lync Server 2010 feature support (cross-premises) You must deploy Lync Server 2010 if you're deploying UM in a cross-premises environment. UM is fully supported and functional with Lync Server 2010, including Message Waiting Indicator (MWI) notifications. Office Communications Server migration (non-cross-premises) If you're deploying or migrating from Exchange 2007 to Exchange 2010 and your Exchange deployment is integrated with Office Communications Server, Exchange 2010 SP1 includes support for migration of SIP URI dial plans that are used with Communications Server. Also, in Exchange 2010 SP1, it's no longer required that you have a Communications Server location profile that has the same name as the phone context property of the SIP URI dial plan. The following table summarizes the supported deployments for Microsoft Exchange, Office Communications Server, and Lync Server 2010.

Supported Deployments
Exchange 2007 SP1, SP2, or SP3 Unified Messaging Office Communications Server 2007 Office Supported only in an Enterprise deployment. Location profile names and UM dial plan phone contexts must match. Supported only in an Enterprise Exchange 2010 RTM Unified Messaging Exchange 2010 SP1 Unified Messaging

Supported only in an Enterprise deployment. Location profile names and UM dial plan phone contexts must match. Supported only in an Enterprise

Not supported

Supported only in an Enterprise deployment.

Communications Server 2007 R2 Lync Server 2010

deployment. Location profile names and UM dial plan phone contexts must match. Supported only in an Enterprise deployment. Location profile names and UM dial plan phone contexts must match.

deployment. Location profile names and UM dial plan phone contexts must match. Supported only in an Enterprise deployment. Location profile names and UM dial plan phone contexts must match.

Location profile names and UM dial plan phone contexts dont have to match. Supported in a cross- premises or Enterprise deployment. Location profile names and UM dial plan phone contexts dont have to match.

Note: Exchange Server 2010 SP1 Unified Messaging no longer supports Office Communications Server 2007. You must use Office Communications Server 2007 R2 or Microsoft Lync Server 2010. Secondary UM dial plan support In SP1, you can add a secondary UM dial plan for a UM-enabled user. Secondary dial plans allow administrators to assign two extension numbers to a UM-enabled user. Or, you can assign a primary extension number in a UM-enabled user's primary dial plan on one PBX or IPX PBX and a secondary extension for that user within a secondary dial plan that exists on a different PBX or IP PBX. When an Exchange 2007 or Exchange 2010 users mailbox is enabled for UM, the administrator is required to specify an extension number and a UM mailbox policy. The extension number is needed by a UM server to identify the user when they call in to Outlook Voice Access to access their mailbox. The UM mailbox policy contains a collection of configuration properties, with values that UM uses to apply to a UM-enabled mailbox that's associated with that UM mailbox policy. One of the properties on the UM mailbox policy is the UM dial plan. The dial plan also contains a set of configurable properties that includes a numbering plan. The numbering plan defined on the UM dial plan doesn't allow for duplicate extension numbers. This ensures that the extension number is unique within the dial plan. By linking the extension number to a user in the UM dial plan, Unified Messaging uniquely identifies a UM-enabled user in an organization. New UM language packs Unified Messaging language packs make it possible for the Exchange 2010 UM server to speak additional languages to callers and recognize languages other than US English (en-US) when callers use Automatic Speech Recognition (ASR) or when voice messages are transcribed. The following is a list of additional UM language packs that are now available but don't contain support for Voice Mail Preview: Catalan (ca-ES) Chinese (Hong Kong) (zh-HK) Danish (Denmark) (da-DK) English (India) (en-IN) Finnish (Finland) (fi-FI) Norwegian (Bokmal) (nb-NO) Russian (ru-RU) The following is a list of additional UM language packs that are now available that do contain support for Voice Mail Preview: English (Canada) (en-CA) Polish (pl-PL) Portuguese (Portugal) (pt-PT) Spanish (Spain) (es-ES) Note: The RTM version of the Spanish (Spain) (es-ES) UM language pack didn't include support for Voice Mail Preview. Voice Mail Preview support was added in SP1. For more information about Voice Mail Preview, see Voice Mail Preview for End Users. By default, when you install the Exchange 2010 Unified Messaging server role, the server will send voice mail previews to UM-enabled users if a supported UM language pack is installed. There are Exchange 2010 Unified Messaging Voice Mail Preview partners that offer enhanced transcription support for the Voice Mail Preview feature. These partners employ people to correct voice mail transcriptions that were created using Automatic Speech Recognition (ASR). Each Voice Mail Preview partner must meet a set of requirements to be certified to interoperate with Exchange 2010 Unified Messaging. If you determine that the voice mail previews sent to your users aren't accurate enough, you can contact one of the certified Voice Mail Preview partners listed on the Microsoft PinPoint web page and sign up with them at an additional cost. For more information, see Voice Mail Preview Advisor for Exchange 2010. You can download the Exchange 2010 UM language packs for SP1 from the Microsoft Download Center. For details, see Install a Unified Messaging Language Pack on a UM Server. Important: To ensure that all Unified Messaging features are available in the UM language packs you install, you must install the Exchange 2010 Client and Server Language Pack on each UM server in the dial plan. If you dont install the Client and Server Language Pack, some features may not work as expected. Some features, like Voice Mail Preview, will work in the language that is configured on the dial plan but when only the UM language pack is installed. However, features like Outlook Voice Access and user interface text wont work in the language by the user without having both the UM language pack and the Client and Server Language Pack installed. To download and install additional client and server language packs on servers in your organization, see Microsoft Exchange Server 2010 SP1 Language Pack Bundle. Call Answering Rules improvements Using Call Answering Rules, end users can control how their incoming calls should be handled. Call Answering Rules are applied to incoming calls much as Inbox rules are applied to incoming e-mail messages. For details, see Understanding Call Answering Rules. There are two updates to Call Answering Rules in Exchange 2010 SP1: In the RTM version, when a caller who's greeted by a call answering rule selects the voice mail option, a UM server first plays the called party's voice mail greeting before prompting the caller with the instruction to leave a voice message. This can be confusing if the user has created custom greetings. In Exchange 2010 SP1, the voice mail greeting is skipped if the caller has chosen to leave a voice message via a call answering rule that's configured. In Exchange 2010 SP1, a missed call notification won't be left for a user if the inbound call reaches the called party using the Find Me feature, if a call transfer succeeds, or if a voice message is successfully left for the user. Unified Communications Managed API/Speech Platform improvements Beginning with Exchange 2010 SP1, the UM server relies on Unified Communications Managed API v. 2.0 (UCMA) for its underlying SIP signaling and speech processing. This dependency requires that the UCMA platform and prerequisites be installed on the UM server before Exchange 2010 UM SP1 installation or upgrade. For details, see Overview of Unified Messaging. As part of this integration with UCMA, you receive the following benefits when you've integrated UM and Lync Server 2010: Unified Messaging reports Quality of Experience (QoE) data to Lync Server 2010 Quality of Experience Monitoring or QMS servers. This is available in both on-premises and cross-premises integrated environments. UM doesn't drop the first incoming call if the first call to the UM server is being made from an Enterprise Voice user who's connected the Internet. In earlier versions of Office Communications Server, the A/V Edge resources that were associated with the Office Communications Server pool didn't communicate with a specific UM server for a specific call. This led to less-than-optimal media quality in some scenarios. With SP1, you can set, on a per UM-server basis, the Office Communications Server pool and associated A/V Edge server resources that should be used for all calls to and from that specific UM server. UM auto attendant update In the RTM version of Exchange 2010, a UM auto attendant would play the after hours greeting and the holiday greeting on holidays. In SP1, UM auto attendant will play only the holiday greeting on a holiday. Exchange 2010 UM Troubleshooting Tool Use the Test-ExchangeUMCallFlow cmdlet to test call flow between UM servers, IP gateways, and SIP servers. With the Test-ExchangeUMCallFlow cmdlet, you can diagnose configuration errors found in telephony components, Exchange 2010 SP1 Unified Messaging settings, and connectivity issues between on-premises and cross-premises Unified Messaging deployments. The Test-ExchangeUMCallFlow cmdlet can be used to diagnose configuration errors specific to call answering scenarios and to test whether voice mail is functioning correctly in Office Communications Server 2007 R2 or Microsoft Lync Server 2010 and non-Office Communication Server 2007 R2 or Lync Server 2010 deployments for both on-premises and cross-premises UM deployments. This cmdlet emulates calls, runs a series of diagnostic tests, and outputs the cause and possible solutions for potential issues that are detected. It also outputs general audio quality metrics for diagnosing audio quality issues related to network

connectivity such as jitter and average packet loss. The Test-ExchangeUMCallFlow cmdlet supports testing UM components in Secured, SIP Secured, and Unsecured calls and can be run either in Gateway or SIPClient modes. Important: The Test-ExchangeUMCallFlow cmdlet must be used to test only the voice mail functionality of a Microsoft Exchange Server 2010 Unified Messaging server that has Service Pack 1 (SP1) installed. The Test-ExchangeUMCallFlow cmdlet can be installed on a local Unified Messaging server or on another 64-bit computer running: The Windows Vista or Windows 7 operating system The Windows Server 2008 or Windows Server 2008 R2 operating system The Test-ExchangeUMCallFlow cmdlet requires the components below be installed on a Windows 7, Windows Vista, or Windows Server 2008 64-bit computer prior to installing the cmdlet: Microsoft .NET Framework 3.5 Service Pack 1 (SP1) To download the service pack, see Microsoft .NET Framework 3.5 Service Pack 1. Microsoft .NET Framework 3.5 Family Update for Windows Vista x64 and Windows Server 2008 x64 updates if the tool will be run on a Windows Vista or Windows Server 2008 computer To download the update, see Microsoft .NET Framework 3.5 Family Update for Windows Vista x64, and Windows Server 2008 x64. Windows Remote Management (WinRM) 2.0 and Windows PowerShell V2 (Windows6.0-KB968930.msu) For more information, see Microsoft Knowledge Base article 968930, Windows Management Framework core package (Windows PowerShell 2.0 and WinRM 2.0). Unified Communications Managed AP1 2.0, Core Runtime (64-bit) To download the UcmaRuntimeWebDownloadX64.msi program file, see Unified Communications Managed API 2.0, Core Runtime (64-bit). The Test-ExchangeUMCallFlow cmdlet isn't included on the Exchange 2010 SP1 DVD or the Exchange 2010 SP1-only download. However, you can download the cmdlet from the Microsoft Download Center.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

New Exchange Core Store Functionality in Exchange 2010 SP1

Exchange 2010 Applies to: Exchange Server 2010 SP1 Topic Last Modified: 2010-07-13 Microsoft Exchange Server 2010 Service Pack 1 (SP1) includes new features, as well as enhancements to features introduced in the release to manufacturing (RTM) version of Exchange Server 2010. This topic describes the new functionality in Exchange 2010 SP1 that's available for the following:

Microsoft Exchange Information Store Mailbox databases Public folders and public folder databases

Exchange Information Store

Exchange 2010 RTM introduced store limits to prevent a single application or single user from using all the available connections to the Microsoft Exchange Information Store. In Exchange 2010 SP1, for any connections by users with administrative privileges, the session limits have been increased to 64,000 maximum sessions per server. For more information, see Exchange Store Limits.

Mailbox Databases
The following describes new functionality related to mailbox databases in Exchange 2010 SP1:

Mailbox Database Repair Requests In Exchange 2010 RTM and earlier, you could repair a mailbox with the Information Store Integrity Checker (Isinteg.exe) tool. To repair mailboxes, you needed to dismount the mailbox database on which that mailbox resided and run the fixes while the database was offline. Exchange 2010 SP1 introduces the New-MailboxRepairRequest cmdlet that allows you to detect and repair a corrupted mailbox while leaving the mailbox database online. For more information, see the following topics: Managing Repair Requests New-MailboxRepairRequest Database Log Growth Troubleshooter The Database Log Growth Troubleshooter script (Troubleshoot-DatabaseSpace.ps1) detects and takes action on excessive log growth that can cause the health of the Mailbox server to be at risk. By default, the configurable troubleshooter runs every 15 minutes to determine the amount of space available on the hard drive. If the hard drive space is less than 25 percent, the troubleshooter runs an algorithm to determine if the problem is caused by excessive log growth. If excessive log growth is the problem, the troubleshooter quarantines or throttles the mailboxes that are causing the excessive log growth. For more information, see Manage Database Log Growth by Using the Troubleshoot-DatabaseSpace.ps1 Script in the Shell. Database Latency Troubleshooter The Database Latency Troubleshooter script (Troubleshoot-DatabaseLatency.ps1) detects and takes action on high latencies on a database. For more information, see Manage Database Latencies by Using the Troubleshoot-DatabaseLatency.ps1 Script in the Shell.

Remove-StoreMailbox
The new Remove-StoreMailbox cmdlet allows you to permanently remove soft-deleted and disconnected mailboxes.

Public Folders and Public Folder Databases

The following changes were made to public folders and public folder databases in Exchange 2010 SP1:

The AggregatePFData.ps1 script now aggregates statistics across all public folder replicas. For more information, see View Public Folder Item Statistics. You can now use the Exchange Management Console to configure client permissions for public folders. For more information, see Use the Public Folder Management Console to Manage Public Folder Settings. The New-PublicFolderDatabaseRepairRequest cmdlet has been added to allow you to detect and correct replication issues in the public folder database. This cmdlet replaces the Isinteg.exe tool. For more information, see Create a Public Folder Database Repair Request.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

New Transport Functionality in Exchange 2010 SP1

Exchange 2010 Applies to: Exchange Server 2010 SP1 Topic Last Modified: 2012-07-19 Microsoft Exchange Server 2010 Service Pack 1 (SP1) includes new features, as well as enhancements to features introduced in the release to manufacturing (RTM) version of Exchange 2010. This topic provides an overview of the following new features and improvements for Transport in Exchange 2010 SP1:

MailTips functionality Message tracking functionality Throttling enhancements Shadow redundancy promotion SMTP failover and load balancing improvements Support for Extended Protection on SMTP communications Send connectors over reliable connections

MailTips Functionality
Here is a brief overview of MailTips features that were added in Exchange 2010 SP1:

MailTips access control over organizational relationships You have granular control over the way MailTips are shared between your organization and other organizations with which you configured an organizational sharing relationship. You can control the types of MailTips that are shared and even designate a specific group of users for which to return MailTips. MailTips monitoring and troubleshooting Several new monitoring capabilities for MailTips were added in Exchange 2010 SP1. New capabilities include changes to event log entries, alerts, and performance monitor counters. For more information, see Understanding MailTips.

Message Tracking Functionality

Here is a brief overview of message tracking features that were added in Exchange 2010 SP1:

Improved error messages for delivery reports There may be situations where a user attempts to access delivery reports for a specific message but is unable to view the report. For example, a user may attempt to access delivery reports for a message immediately after sending it, but before the tracking information for that message is inserted into the logs. In these types of scenarios, the messages displayed to the users have been greatly improved, providing specific explanations as to why the information isn't available. Message tracking monitoring and troubleshooting Several new monitoring capabilities for message tracking were added in Exchange 2010 SP1. These include new event log entries, alerts, and performance monitor counters. Message tracking trace levels When you're troubleshooting message tracking, you can now request complete logs of every operation that was executed by a Client Access server processing a delivery report request. For more information, see Understanding Message Tracking.

Throttling Enhancements
Transport servers in Exchange 2010 SP1 keep track of the current state of the overall Exchange organization and modify the way they handle messages accordingly. This allows the Transport servers to respond proactively to potentially problematic situations, improving the reliability of the overall message delivery. In Exchange 2010 SP1, Transport servers maintain a running average delivery cost of messages sent by individual senders. If a user keeps sending costly messages, such as those addressed to large audiences or tha have large attachments, Transport servers start to give priority to other messages that have a lower cost before it processes messages from that sender. For example, if a user is sending multiple messages that have 10MB attachments, Transport starts to first process other messages that dont have attachments before it handles additional messages from this particular sender. Transport also keeps track of the RPC utilization of mailbox servers. A Hub Transport server makes RPC connections to a mailbox server for message delivery. If a Hub Transport server detects that a mailbox server is under RPC resource pressure, it scales back the RPC sessions that it opens to that mailbox server. This way, interactive client connections to the mailbox server take precedence over message delivery when it comes to utilizing RPC resources on a mailbox server. Back pressure is a system resource monitoring feature of the Microsoft Exchange Transport service that exists on Hub Transport and Edge Transport servers In Exchange 2010. Exchange Transport can detect when vital resources, such as available hard disk space and memory, are under pressure, and take action to try to prevent service unavailability. All configuration options for back pressure are available in the EdgeTransport.exe.config application configuration file. In Exchange 2010 Service Pack 1, the default values in EdgeTransport.exe.config are revised for following parameters:

SmtpStartThrottlingDelayInterval: decreased from 10 seconds to 1 second SmtpStepThrottlingDelayInterval: decreased from 5 seconds to 1 second For more information about the EdgeTransport.exe.config file, see Understanding the EdgeTransport.exe.Config File. For more information about back pressure configuration, see Understanding Back Pressure. For more information about throttling, see Understanding Message Throttling.

Shadow Redundancy Promotion

Exchange 2010 introduced the shadow redundancy feature to minimize the loss of any message during delivery after it enters the Exchange organization. Exchange Transport servers achieve this by using the shadow redundancy SMTP protocol extension. However, in any organization Exchange Transport servers need to communicate with other third-party SMTP servers that may not support the shadow redundancy protocol. This is especially true with Edge Transport servers that handle message traffic with various hosts on the Internet. When receiving messages from hosts that don't support shadow redundancy in Exchange 2010 RTM, Transport servers delay sending acknowledgement to incoming messages until they verify final delivery within the organization. However, when a specific threshold was reached, the Transport server issued an acknowledgement even if final delivery wasn't verified. This presented a scenario where messages received from hosts that don't support shadow redundancy can be lost in transit. To address this issue, a new feature called shadow redundancy promotion is introduced in Exchange 2010 SP1. When faced with the scenario described above, instead of issuing an acknowledgment without delivery confirmation, a Transport server now routes the message to any other Transport server within the site so that the message is protected by shadow redundancy. There are additional details about how this scenario works. To learn more, see Understanding Shadow Redundancy.

SMTP Failover and Load Balancing Improvements

Exchange 2010 SP1 improves the way Transport servers detect unhealthy servers and use enhanced DNS. Enhanced DNS distributes the load evenly when all servers are healthy, but in the case of an unavailable server, the load distribution among the remaining healthy servers may not be evenly balanced. To address this issue, each Exchange 2010 SP1 Transport server maintains a list of unavailable servers. When routing a message, each server uses this information to filter out the known unavailable servers from the set of target servers. For example, assume that a Hub Transport server needs to route several messages to another Active Directory site which has three Hub Transport servers (Hub1, Hub2, and Hub3). If the server knows that Hub2 is unavailable, it'll remove that server from the list of possible targets and only route to Hub1 and Hub3. It'll assume only two servers, Hub1 and Hub3, exist in the remote Active Directory site when load balancing messages. As a result, Exchange 2010 SP1 Transport servers always distribute the load evenly between healthy servers and avoid any servers that are unavailable for any reason. For more information, see Understanding SMTP Failover and Load Balancing in Transport.

Support for Extended Protection on SMTP Communications

Windows offers channel binding to protect NTLM authentication over encrypted channels from authentication relay attacks. In Exchange 2010, all services provided by Exchange have been updated to support Extended Protection for Authentication. For more information, see Microsoft Knowledge Base article 968389, Extended Protection for Authentication. To support this feature in Transport, the Receive connectors have been updated. You can allow, require, or disable Extended Protection for Authentication on your Receive connectors. For more information, see Understanding Receive Connectors.

Send Connectors over Reliable Connections

With Exchange 2010 SP1, several new features were added to the Send connectors. Most changes are to support coexistence with Exchange Online. In addition, the ability to downgrade connection failures was added to the Send connectors. You may have dedicated Send connectors that are responsible for transmitting messages over well-defined communication channels that are expected to always be available, such as a Send connector dedicated to send messages to Exchange Online. On such connections, many of the typical errors that are possible on ordinary destinations on the Internet aren't expected. In this scenario, you may want to treat any communication errors as transient as opposed to issuing non-delivery reports (NDRs). With Exchange 2010 SP1, you can configure a Send connector to downgrade authentication and name resolution errors, which would normally result in an NDR, to transient errors. In these cases, Exchange will attempt delivery again instead of issuing an NDR. For more information, see Understanding Send Connectors.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Release Notes for Exchange Server 2010 SP1

Exchange 2010 Applies to: Exchange Server 2010 SP1 Topic Last Modified: 2011-04-19 For important legal information, see Legal Notice later in this document. Welcome to Microsoft Exchange Server 2010. This document contains the following sections:

Functionality Available in Exchange 2010 SP1 Installing Exchange 2010 SP1 Mailbox Moves Unified Messaging Legal Notice

Functionality Available in Exchange 2010 SP1

Exchange 2010 Service Pack 1 (SP1) adds new and revised functionality. For more information, see What's New in Exchange 2010 SP1.

Installing Exchange 2010 SP1

Consider the following when you deploy Exchange 2010 SP1:

You can now select a new option that installs the required Microsoft Windows operating system roles and features for each selected Exchange 2010 SP1 server role. You can only install Exchange 2010 SP1 on computers running Windows Server 2008 Service Pack 2 (SP2) and Windows Server 2008 R2. Although it isn't a recommended configuration, single-label Domain Name System (DNS) domain names are now supported for use with Exchange 2010 SP1. If you're running the beta release of Exchange 2010, you must uninstall the beta release before you install the SP1 version of Exchange 2010. If you upgrade an Edge Transport server that's running Forefront Threat Management Gateway (TMG) and has Forefront Protection for Exchange Server (FPE) enabled for SMTP protection, the Forefront TMG Managed Control service may fail to start. For detailed information about the requirements and steps for installing Exchange 2010 SP1, see the following topics:

Exchange 2010 Prerequisites Exchange 2010 System Requirements Understanding a New Installation of Exchange 2010 Understanding Upgrade to Exchange 2010 Upgrade Exchange 2010 to Exchange 2010 SP1, Exchange 2010 SP2, or Exchange 2010 SP3

Mailbox Moves
The process for moving mailboxes has changed to help make sure that no data is unintentionally lost due to issues that may occur around the same time as a move, such as a lossy failover on the target database. When mailboxes are moved from an Exchange 2010 SP1 database to any other database, Exchange no longer fully deletes the mailbox from the source database immediately upon completion of the move. Instead, the mailbox in the source mailbox database is switched to a soft-deleted state, which allows mailbox data to be accessed during a mailbox restore operation by using the new MailboxRestoreRequest set of cmdlets. These soft-deleted mailboxes are visible when running the Get-MailboxStatistics cmdlet against a database and can be identified by having the property DisconnectReason with a value of SoftDeleted. The soft-deleted mailboxes will be retained in the source database until either the deleted mailbox retention period expires or the mailbox is purged by using the Remove-StoreMailbox cmdlet. As a result of this change, if you're performing mailbox moves to reduce the amount of space being used in a database, you must also perform the additional step of purging the soft-deleted mailbox. Soft-deleted mailboxes can't be reconnected. Note: You wont be able to view soft-deleted mailboxes by using the Get-MailboxStatistics cmdlet in Exchange versions earlier than Exchange 2010 SP1. If necessary, you can restore data from these soft-deleted mailboxes by using the MailboxRestoreRequest set of cmdlets, which is initiated with the NewMailboxRestoreRequest cmdlet. The MailboxRestoreRequest cmdlets replace the legacy Restore-Mailbox cmdlet. In addition to having the same capabilities as the Restore-Mailbox cmdlet, the MailboxRestoreRequest cmdlets perform additional tasks, including the ability to:

Restore from rehomed or soft-deleted mailboxes that aren't in a recovery database. Be processed asynchronously (like a mailbox move in Exchange 2010). Restore data into an archive mailbox.

Known Issues with Mailbox Moves

The following are known issues associated with mailbox moves.

MRSProxy

An Exchange 2010 SP1 change to the Mailbox Replication Proxy (MRSProxy) service requires you to apply a Microsoft .NET Framework hotfix before you can move mailboxes across forests. If you don't apply the .NET Framework hotfix, you may receive transient exceptions on the remote forest due to MRSProxy failures, which leads to a series of "another administrator is moving the mailbox" error messages. Sometimes, the move request recovers and retries the move, but eventually the move will fail due to too many transient failures. In Event Viewer on the Client Access server, you will receive an error message similar to the following: Log Name: Application Source:.NET Runtime Date:6/14/2010 3:56:55 PM Event ID: 1023 Task Category: None Level: Error Keywords: Classic User: N/A Computer: CAS01.contoso.com

Description: .NET Runtime version 2.0.50727.4200 - Fatal Execution Engine Error (000007FEF884664E) (80131506) You need to apply the hotfix to all Exchange 2010 SP1 Client Access servers in both forests. For more information about this hotfix and how to download it, see Microsoft Knowledge Base article 971030, FIX: An access violation occurs when you run a .NET Framework 2.0-based application that has a virtual call the IList<T>, IEnumerable<T>, or ICollection<T> interface in an LCG method.

Move Request Versioning

When performing a cross-forest mailbox move, the Exchange 2010 RTM version of the Microsoft Exchange Mailbox Replication service (MRS) and the MRSProxy service can't log into an Exchange 2010 SP1 Mailbox server. This functionality is intentional. It prevents errors when moving mailboxes across Exchange versions to provide for new functionality such as soft-deletes. To prevent this issue from occurring, you can do one of the following:

Make sure that all Client Access servers in the remote and local forests are running the same or a later version of Exchange than the Mailbox servers in the remote and local forests. In the remote forest, make sure you haven't mixed Exchange servers of different versions behind the same network load balancer (NLB) end point. Initiate cross-forest moves from the later version of Exchange.

Autodiscover
In the RTM version of Exchange 2010, when you move a mailbox across forests, the source mailbox is converted to a mail-enabled user. If the mailbox has a personal archive, after the move is complete, the msExchArchiveDatabaseLink attribute isn't cleared from the mail-enabled user in the source forest, and the new mailbox in the target forest also gets this attribute stamped with the database in which the archive now resides. If this attribute is present on the mail-enabled user, it will point to a database in the source forest. As a result, when you upgrade to Exchange 2010 SP1, Autodiscover and Outlook can't determine where the mailbox resides because the mail-enabled user object and the mailbox object are pointing to different databases within different forests. Therefore, before you upgrade to Exchange 2010 SP1, you must clear the msExchArchiveDatabaseLink attribute manually from Active Directory for each affected mail-enabled user. You can use a tool such as ADSIEdit to remove this property. For more information, see Microsoft Knowledge Base article 2387770, When using Autodiscover Outlook fails to connect to an Exchange 2010 SP1 mailbox with "Unable to open your default e-mail folders" if the user was moved cross forest.

Unified Messaging
Consider the following issues when you install and configure Exchange 2010 SP1 with Unified Messaging.

UM Language Packs
The Unified Messaging (UM) language packs for Exchange 2010 SP1 are intended to be used only on Unified Messaging servers running Exchange 2010 SP1. They must not be installed on 64-bit Unified Messaging servers running the release to manufacturing (RTM) version of Exchange 2010. These new UM language packs allow a Unified Messaging server running Exchange 2010 SP1 to speak additional languages to callers and recognize other languages when callers use Automatic Speech Recognition (ASR) or when voice messages are transcribed. UM language packs contain:

Prerecorded prompts, for example: "After the tone, please record your message. When you've finished recording, hang up, or press the # key for more options." These prompts are in the language of the UM language pack. Text-to-Speech (TTS) data and executable code so that text content (such as e-mail, calendar, and contact information) can be read to callers in the language of the UM language pack. ASR data and executable code, which allows callers to interact with Unified Messaging using the voice user interface (Outlook Voice Access) in the language of the UM language pack. Support for Voice Mail Preview, which adds a text version of voice mail messages that can be read from e-mail clients such as Microsoft Outlook or Microsoft Office Outlook Web App. The Voice Mail Preview feature isn't available in all UM language packs. The following is a list of UM language packs in Exchange 2010 SP1 that contain support for Voice Mail Preview. The language packs marked with an asterisk (*) are

new in SP1:

English (United States) (en-US) English (Canada) (en-CA) * French (France) (fr-FR) Italian (Italy) (it-IT) Polish (pl-PL) * Portuguese (Portugal) (pt-PT) * Spanish (Spain) (es-ES) *

Known Issues
The following are known issues associated with UM language packs:

Installation issues When you're installing a UM language pack, you may encounter the following error message: "This specified role, UmLanguagePack, isn't defined in the configuration file." To work around the problem, you can delete the C:\Program Files\Microsoft\Exchange Server\V14\Bin\en\ExBPA.Config.xml file, and then restart the language pack installation. General recommendations and considerations when you're using UM language packs for name pronunciation. The following issues are associated with name pronunciation: The actual names should be recorded by UM-enabled users when they're setting up their voice mail (signing in to Outlook Voice Access for the first time). If a recorded name is available, it will always be spoken to a caller by Unified Messaging. If a recorded name isn't available, Unified Messaging will try to speak the user's display name phonetically. This requires the Unified Messaging server to use TTS synthesis to speak the user's name. If a phonetic display name isn't available for the user, Unified Messaging will try to speak the user's display name. This also requires TTS synthesis. The problems (described later in this document) with the pronunciation of names refer to the cases in which a recorded name or phonetic display name is used by a Unified Messaging server to speak the name of the user. Language-specific issues. Some language packs may have problems with the pronunciation of names. The following problems are listed by language pack: Japanese In the case of some Romaji names (Japanese names spelled using Roman characters), instead of pronouncing the name in its entirety, Unified Messaging may read the name spelled out letter-by-letter, for example, instead of "Sugimoto," Unified Messaging may read "s-u-g-i-m-o-t-o." In addition, Unified Messaging may not read English names spelled out using Roman characters, remaining silent in place of a name. Russian Some Romanized Russian names, as well as English names, might be pronounced in an unnatural manner. English (India) While attempting to switch the language used to read e-mail messages in Outlook Voice Access, Unified Messaging may not recognize the name of the requested culture. To work around this issue, try to use alternative names, for example, instead of "Chinese," use "Chinese P.R.C." or "Chinese Hong Kong." Caution: Deploying the Exchange 2010 SP1 English (India) (en-IN) Unified Messaging language pack in organizations that include Exchange Server 2007 servers running on Windows Server 2003 will cause the Exchange 2007 servers to fail. English (US) Unified Messaging may not pronounce names written with characters from non-Roman alphabets. Chinese (Hong Kong) Unified Messaging may not pronounce names written using characters from alphabets other than Chinese (H.K.). Danish When reporting hours, Unified Messaging may unnecessarily repeat the word "klokken," for example, "ankom I gr klokken klokken 8:21."

Exchange 2010 UM Troubleshooting Tool

You can use the Test-ExchangeUMCallFlow cmdlet to test call flow between Unified Messaging servers, IP gateways, and Session Initiation Protocol (SIP) servers. This cmdlet can be used to diagnose configuration errors found in telephony components, Exchange 2010 SP1 Unified Messaging settings, and connectivity issues between on-premises and cross-premises Unified Messaging deployments. The Test-ExchangeUMCallFlow cmdlet can also be used to diagnose configuration errors specific to call answering scenarios and to test whether voice mail is functioning correctly, both on-premises and cross-premises, for the following:

Deployments that use Microsoft Office Communications Server 2007 R2 or Microsoft Lync Server 2010 Deployments that aren't using Communications Server 2007 R2 or Lync Server 2010 This cmdlet emulates calls and runs a series of diagnostic tests that provide reasons, and possible solutions, for issues that are detected. It also provides metrics for diagnosing audio quality issues related to network connectivity, such as jitter and average packet loss. The Test-ExchangeUMCallFlow cmdlet supports testing Unified Messaging components Secured, SIP Secured, and Unsecured modes and can be run either in Gateway or SIPClient modes. Important: The Test-ExchangeUMCallFlow cmdlet must be used to test only the voice mail functionality of an Exchange 2010 Unified Messaging server that has Exchange 2010 SP1 installed. The Test-ExchangeUMCallFlow cmdlet can be installed on a local Unified Messaging server or on another 64-bit computer that's running the:

Windows Vista or Windows 7 operating system. Windows Server 2008 or Windows Server 2008 R2 operating system. The Test-ExchangeUMCallFlow cmdlet requires that the components in the following list be installed on a computer running Windows Vista, Windows 7, or the 64-bit version of Windows Server 2008 before the cmdlet is installed:

.NET Framework 3.5 SP1. For details, see Microsoft .NET Framework 3.5 Service Pack 1. .NET Framework 3.5 Family Update for the 64-bit version of Windows Vista, and the 64-bit version updates of Windows Server 2008 if the tool will be run on a computer running Windows Vista or Windows Server 2008. For details, see Microsoft .NET Framework 3.5 Family Update for Windows Vista x64, and Windows Server 2008 x64. Windows Remote Management (WinRM) 2.0 and Windows PowerShell V2 (Windows6.0-KB968930.msu). For details, see Windows Management Framework Core package (Windows PowerShell 2.0 and WinRM 2.0). Microsoft Unified Communications Managed API 2.0 Core Runtime (UcmaRuntimeWebDownloadX64.msi). For details, see Unified Communications Managed API 2.0, Core Runtime (64-bit). The Test-ExchangeUMCallFlow cmdlet isn't included on the Exchange 2010 SP1 DVD or in the download for Exchange 2010 SP1 only. However, you can download the Test-ExchangeUMCallFlow cmdlet from the Microsoft Download Center. For details, see Unified Messaging Troubleshooting Tool. Important: The Diversion parameter in the UM troubleshooting tool doesn't currently accept multiple History-Info headers. When you're running the tool in Gateway mode, the Diversion parameter must be provided. This can be in the form of a Diversion or a History-Info header. When you specify diversion numbers using History-Info headers, Unified Communications Managed API 2.0 requires that at least two History-Info headers be provided. For example: "<sip:66242@10.197.22.149;user=phone >; index=1, \ < sip:66242@10.197.22.149?Reason=SIP; cause=480; \ text="Request Timeout">;index=1.1, \ ;index=1.2"

Office Communications Server 2007 and Lync Server 2010

Office Communications Server 2007 R2 or Microsoft Lync Server 2010 (the next generation of Office Communications Server) is required with Unified Messaging in Exchange 2010 SP1. The following table describes supported deployments.

Supported deployments
Office Communications Server or Lync Server version Office Communications Server 2007 Office Communications Server 2007 R2 Lync Server 2010 Exchange Server 2007 SP1, SP2, or SP3 Unified Messaging.

Exchange 2010 RTM Unified Messaging.

Exchange 2010 SP1 Unified Messaging.

Supported only in an enterprise deployment. Location profile names and UM dial plan phone contexts must match. Supported only in an enterprise deployment. Location profile names and UM dial plan phone contexts must match. Supported only in an enterprise deployment. Location profile names and UM dial plan phone contexts must match.

Supported only in an enterprise deployment. Location profile names and UM dial plan phone contexts must match. Supported only in an enterprise deployment. Location profile names and UM dial plan phone contexts must match. Supported only in an enterprise deployment. Location profile names and UM dial plan phone contexts must match.

Not supported.

Supported only in an enterprise deployment. Location profile names and UM dial plan phone contexts don't have to match. Supported in a cross-premises or enterprise deployment. Location profile names and UM dial plan phone contexts don't have to match.

Note: Exchange 2010 SP1 Unified Messaging no longer supports Office Communications Server 2007. You must use Office Communications Server 2007 R2 or Lync Server 2010.

Legal Notice
This document is provided as-is. Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it. Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred. This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes. 2010 Microsoft Corporation. All rights reserved. Microsoft, MS-DOS, Windows, Windows Media, Windows Mobile, Windows NT, Windows PowerShell, Windows Server, Windows Vista, Active Directory, ActiveSync, Entourage, Excel, Forefront, Internet Explorer, Outlook, PowerPoint, SharePoint, SmartScreen, Visual Basic, Xbox, Xbox 360, the Xbox sphere logo, Zune, and the Zune logo are trademarks of the Microsoft group of companies. All other trademarks are property of their respective owners. Arabic Spelling Checker, Grammar Checker, and Thesaurus, 1992-2006 developed by COLTEC Egypt. All rights reserved. Italian grammar checker with Cogito technology 1994-2006 Expert System Modena. All rights reserved. Italian thesaurus 1994-2006 Expert System Modena. All rights reserved. Brazilian Portuguese Speller, Hyphenator, Thesaurus and Grammar. Itautec Philco S.A., Grupo Itautec Philco Danish speller: Copyright Lingsoft, Inc. 2005. Two-Level Compiler: Copyright Xerox Corporation 1994. All rights reserved. Danish hyphenator: Copyright Lingsoft, Inc. 2005.

Two-Level Compiler. Copyright Xerox Corporation 1994. All rights reserved. German speller. Copyright Lingsoft, Inc. 2005. Two-Level Compiler: Copyright Xerox Corporation 1994. All rights reserved. German hyphenator. Copyright Lingsoft, Inc. 2005. Two-Level Compiler: Copyright Xerox Corporation 1994. All rights reserved. German inflecting thesaurus: Copyright Lingsoft, Inc. 2005. German thesaurus: Copyright Karl Peltzer and Reinhard von Norman and Ott Verlag and Druck AG Thun/Switzerland 1996. Two-Level Compiler: Copyright Xerox Corporation 1994. All rights reserved. Norwegian bokml speller: Copyright Lingsoft, Inc. 2005. Norwegian works: Copyright J. W. Cappelens Forlag AS 1996, 1997: Norsk ordbok: Bokml: Copyright J. W. Cappelens Forlag AS 1996. CAPLEX: Copyright J. W. Cappelens Forlag AS 1997. Two-Level Compiler: Copyright Xerox Corporation 1994. All rights reserved. Norwegian bokml hyphenator: Copyright Lingsoft, Inc. 2005. Norwegian works: Copyright J. W. Cappelens Forlag AS 1996, 1997: Norsk ordbok: Bokml: Copyright J. W. Cappelens Forlag AS 1996. CAPLEX: Copyright J. W. Cappelens Forlag AS 1997. Two-Level Compiler. Copyright Xerox Corporation 1994. All rights reserved. Norwegian nynorsk speller: Copyright Lingsoft, Inc. 2005. February 1998 electronic version of Nynorskordboka: Copyright University of Oslo and The Norwegian Language Council 1998. Two-Level Compiler. Copyright Xerox Corporation 1994. All rights reserved. Norwegian nynorsk hyphenator: Copyright Lingsoft, Inc. 2005. February 1998 electronic version of Nynorskordboka: Copyright University of Oslo and The Norwegian Language Council 1998. Two-Level Compiler: Copyright Xerox Corporation 1994. All rights reserved. Swedish grammar checker: Copyright Lingsoft, Inc. 2005. Constraint Grammar Parser: Copyright Pasi Tapanainen 1993 and Lingsoft, Inc. 2005. Two-Level Compiler: Copyright Xerox Corporation 1994. All rights reserved. Hebrew thesaurus and Hebrew language spell checker, 2009 Melingo. All rights reserved. Portuguese Spell Checker, Hyphenator, Grammar Checker and Thesaurus 1995-2005 Priberam Informtica, Lda. Thesauruss content based on dictionrio de Sinnimos from Porto Editora, Lda. All rights reserved. Portions of security system based on BSAFE and TIPEM software from RSA Data Security, Inc. ORFOTM Grammar Checker JSC Informatics, 1990-2002. All rights reserved. , 1990-2002. . The following components are licensed to Microsoft in object code form by Stellent Chicago Sales, Inc.: Components Version 8.0 Outside In HTML Export Version 8.0

Platforms Supported Version 8.0: Windows Intel (32 bit binaries) Windows 2000/XP/Server 2003 Windows Itanium (64 bit binaries) Windows.NET Server 2003 Enterprise Edition for Itanium Windows AMD (64 bit binaries) Windows Server 2003, Enterprise Edition for AMD Opteron

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Issues That Are Fixed in Exchange 2010 SP1

Exchange 2010 Topic Last Modified: 2012-03-07 This topic provides the list of issues that are fixed in Microsoft Exchange Server 2010 Service Pack 1 (SP1). For more information about Exchange 2010 SP1, see the following topics:

To learn more about the new features in Exchange 2010 SP1, see What's New in Exchange 2010 SP1. To learn more about known issues that affect SP1, see Release Notes for Exchange Server 2010 SP1. To obtain Exchange 2010 SP1, visit the following Microsoft Download Center website: Microsoft Exchange Server 2010 Service Pack 1 (SP1).

Issues that are Fixed

Exchange 2010 SP1 includes the changes made in the following Exchange 2010 RTM rollups:

Description of Update Rollup 5 for Microsoft Exchange Server 2010 Release to Manufacturing Description of Update Rollup 4 for Microsoft Exchange Server 2010 Release To Manufacturing Description of Update Rollup 3 for Microsoft Exchange Server 2010 Release to Manufacturing Description of Update Rollup 2 for Exchange Server 2010: February 18, 2010 Update Rollup 1 for Exchange Server 2010

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

What's New in Exchange 2010

Exchange 2010 Applies to: Exchange Server 2010 Topic Last Modified: 2012-07-23 Microsoft Exchange Server 2010 brings a new and rich set of technologies, features, and services to the Exchange Server product line. New features and functionality in Exchange 2010 support several key concepts:

Flexible and reliable Anywhere access Protection and compliance The following sections provide you with an overview of some of the important new features and functionality, which you can use when you're planning, deploying, and administering your Exchange 2010 organization. (For information about features that have been discontinued or de-emphasized from Microsoft Exchange Server 2003 or Exchange Server 2007 to Exchange 2010, see Discontinued Features.) For information about the features and changes that have been added in Exchange 2010 SP1, see What's New in Exchange 2010 SP1.

Flexible and Reliable

The pressure to optimize your IT infrastructure to respond to changing business conditions demands agility and that means investing in solutions that provide you and your organization choice. Exchange 2010 gives you the flexibility to tailor your deployment based on your organization's unique needs and a simplified way to help keep e-mail continuously available for your users.

High Availability Functionality

Exchange 2010 integrates high availability into the core architecture of Exchange to enable customers of all sizes and in all segments to economically deploy a messaging continuity service in their organization. Exchange 2010 includes many changes to its core architecture. In Exchange 2010, new features such as incremental deployment, mailbox database copies, and database availability groups work with other features such as shadow redundancy and transport dumpster to provide a new, unified platform for high availability and site resilience. For more information about high availability features, see New High Availability and Site Resilience Functionality.

Exchange Store and Mailbox Database Functionality

The following is a list of core store functionality that's included or has been changed in Exchange 2010:

Deprecated storage groups Mailbox databases no longer connected to the server object Improvements in Extensible Storage Engine (ESE) for high availability, performance, and database mobility Flattened Outlook store schema Enhanced reporting with public folders For more information about Exchange store and mailbox database features, see New Exchange Core Store Functionality.

Permissions Functionality
In Exchange 2010, Role Based Access Control (RBAC) replaces the permissions model used in Exchange 2007. Using RBAC, you can define extremely broad or extremely precise permissions models based on the roles of your administrators and users. For administrators and specialist users, management role groups define what these users can manage in the organization. Role groups associate role group members to a set of management roles that define what the members can do. By adding or removing users as members of role groups, and adding or removing role assignments to or from a role group, you can control what aspects of the organization the members can manage. For end users, management role assignment policies define what users can configure on their own mailbox. Assignment policies are applied to every mailbox either by default or manually, and enable you to control whether users can change their personal information, contact information, distribution group membership, and so on. Both role groups and role assignment policies are assigned management roles. Management roles control access to the cmdlets and parameters required to perform a task. For example, if a cmdlet exists on a management role, and that role is assigned to a role group, the members of that role group can then use that cmdlet. For more information about RBAC features, see Understanding Permissions.

Transport and Routing Functionality

The following is a list of new transport and routing functionality included in Exchange 2010:

Shadow redundancy MailTips Moderated transport Federated delivery Latency service level agreement (SLA) management End-to-end message tracking Incremental EdgeSync Transport rules integration with AD RMS Transport dumpster improvements Transport database improvements For more information about transport features, see New Transport Functionality.

Exchange Server 2010 Deployment Assistant

Exchange Server 2010 introduces the Exchange Server Deployment Assistant, or ExDeploy, a new Web-based tool that can help you with your Exchange deployment. ExDeploy asks you a few questions about your current environment and then generates a custom checklist and procedures that help simplify your deployment. For more information, see Exchange Server Deployment Assistant.

Administration Functionality in the Exchange Management Console

The following is a list of the new core Exchange Management Console (EMC) features included in Exchange 2010. The core EMC refers to new functionality that affects how you use the EMC, and not how you use specific features:

Ability to add Exchange forests to the console tree Customer Feedback start tab Community and Resources EMC command logging Property dialog box command exposure RBAC permissions aware for the EMC Online Exchange Help For more information about EMC features, see New Administrative Functionality in the Exchange Management Console.

Administration Functionality in the Exchange Management Shell

The following is a list of features available in the new Exchange Management Shell:

Remote administration With the new Shell, you can connect to remote servers running Exchange 2010 across the network with only Windows Management Framework installed, which includes Windows PowerShell. For more information, see Overview of Exchange Management Shell. RBAC integration The Shell works with RBAC to give you and your users access only to the cmdlets and parameters you and they are allowed to use. If your permissions don't allow you to configure a certain feature, you aren't given access to the cmdlets, parameters, or both, that manage that feature. For more information, see Understanding Role Based Access Control. Administrator audit logging Actions that result in the modification of Exchange organization configuration and other object properties in the EMC, the Web management interface, and the Shell can now be logged for later review. For more information, see Overview of Administrator Audit Logging. Improved multiple-valued property syntax Instead of running multiple commands to add and remove values from a single property, you can now add and remove values with a single command. For more information, see Modifying Multivalued Properties.

Exchange Control Panel

Administrators can use the Exchange Control Panel for Outlook Web App to manage some on-premises tasks. The following is a list of the administrative features available:

Text messaging integration Voice messaging integration Multiple mailbox search Additional proxy addresses for mailboxes Moderation and approval for distribution list submission In addition, users have self-service capabilities in that they can perform administrative tasks via the Exchange Control Panel. The ECP enables users to perform common tasks without having to call the help desk. This allows your users to be more productive and allows IT staff to deliver more, while reducing support costs. For more information, see Configure ECP Virtual Directory Properties.

Mailbox and Recipient Functionality

The following is a list of the new mailbox and recipient functionality that's included or has been changed in Exchange 2010:

Ability for users to share information, such as calendar free/busy information and contacts with users who reside in a different organization Improved scheduling and configuring for resource mailbox calendar processing

Ability to move a mailbox while the end user is still accessing it Additional parameters added to distribution group cmdlets to allow users to create and manage their own distribution groups in Outlook Web App and Exchange 2010 Ability to appoint a moderator to regulate the flow of messages sent to a distribution group Ability to manage folder-level permissions for all folders within a user's mailbox Expanded bulk recipient management to allow you to bulk manage recipient properties Ability to send mail to recipients from the EMC For more information about mailbox and recipient features, see New Mailbox and Recipient Functionality.

Exchange Web Services Managed API 1.0

The Microsoft Exchange Web Services (EWS) Managed API 1.0 provides a managed interface for developing client applications that use Exchange Web Services. Beginning with Exchange 2007 Service Pack 1 (SP1), the EWS Managed API simplifies the implementation of applications that communicate with Exchange. Built on the Exchange Web Services SOAP protocol and Autodiscover, the EWS Managed API provides a .NET interface to Exchange Web Services that's designed to be easy to learn, use, and maintain. For more information, see Introducing the Exchange Web Services Managed API 1.0 and Microsoft Exchange Web Services Managed API 1.0.

Client Throttling Functionality to Manage System Performance

Exchange 2010 uses client throttling policies to manage the performance of your Exchange organization. To do this, Exchange tracks the resources that each user consumes and enforces connection bandwidth limits as necessary. Some of the benefits of client throttling include making sure that:

Users aren't intentionally or unintentionally taxing the system. Users of various connectivity methods are proportionally sharing resources. You manage client throttling policies with Shell cmdlets. For more information about client throttling policies, see Understanding Client Throttling Policies.

Anywhere Access
Enhancements in Exchange 2010 helps users get more done by helping them to access all of their communicationse-mail, voice mail, instant messagingfrom virtually any platform, Web-browser, or device through industry standard protocols. Managing the flow of information into and out of an individuals inbox daily can create overload and affect productivity and profitability. In response to this challenge, Exchange 2010 adds new productivity features that can help users more easily organize and effectively prioritize their communications.

Unified Messaging Features

The following is a list of new Unified Messaging features included in Exchange 2010:

Call answering rules Additional language support included in Outlook Voice Access Enhancements to name lookup from caller ID Voice Mail Preview Message Waiting Indicator Missed call and voice mail notifications using text messaging Protected Voice Mail Incoming fax support Addressing to groups (personal distribution lists) support Built-in Unified Messaging administrative roles For more information about Unified Messaging and voice mail features, see New Unified Messaging Functionality and Voice Mail Features.

Outlook Web App Features

The following is a list of new features in Outlook Web App included in Exchange 2010:

Favorites in the navigation pane Search folders Message filtering Ability to set categories in the message list Options in the Web management interface for Outlook Web App Side-by-side view for calendars Multiple client language support Ability to attach messages to messages Expanded right-click capabilities Integration with Office Communicator, including presence, chat, and a contact list Conversation view Ability to send and receive text messages from Outlook Web App Outlook Web App mailbox policies For more information about Outlook Web App features, see Understanding Outlook Web App.

Exchange ActiveSync Features

The following is a list of new Exchange ActiveSync features included in Exchange 2010:

Conversation grouping of e-mail messages Ability to synchronize or not synchronize an entire conversation Synchronization of SMS messages with a user's Exchange mailbox Support for viewing of message reply status Support for availability information for contacts

Text Messaging Features

The following is a list of new text messaging features included in Exchange 2010:

Missed call and voice mail notifications Calendar and agenda updates Text messages sent and received through Outlook Web App and Outlook 2010 Text message synchronization with a mobile phone

POP3 and IMAP4 Cross-Site Connectivity Support

Cross-site POP3 and IMAP4 client connectivity is supported by default in Exchange 2010. For more information about POP3 and IMAP4 client connectivity features, see Understanding POP3 and IMAP4.

Protection and Compliance

Exchange 2010 delivers new, integrated e-mail archiving and retention functionality, including granular multi-mailbox search and immediate legal hold. Exchange 2010 also helps you to better protect your companys communications and e-mail through centrally managed information control capabilities. This includes the ability to more effectively intercept, moderate, encrypt, and block e-mail messages. Together, this functionality provides you with a flexible range of protection and control options, whether you want to automatically enforce controls or empower users to implement their own data protection.

Messaging Policy and Compliance Features

Exchange 2010 compliance features make retention independent of users' mailbox management and filing habits, and ensure retention policies are applied continuously. The following is a list of new messaging and compliance features included in Exchange 2010:

Additional messaging records management (MRM) functionality to apply message retention policies Personal Archive feature to provide users with online archive mailboxes and help eliminate .pst files Mailbox search features for cross-mailbox search with Advanced Query Syntax (AQS) support Additional transport rules predicates and actions For more information about messaging policy and compliance features, see New Messaging Policy and Compliance Functionality.

IRM-Protected E-Mail Functionality with Active Directory Rights Management Services

The following is a list of new Information Rights Management (IRM)-protected e-mail functionality with Active Directory Rights Management Services (AD RMS) included in Exchange 2010:

Microsoft Outlook protection rules, to apply IRM-protection to messages in Outlook 2010 Transport protection rules, to apply IRM protection to messages based on rule conditions Persistent protection of attachments in IRM-protected messages Support for AD RMS templates Support for IRM in Microsoft Office Outlook Web App Transport decryption, to decrypt IRM-protected messages to apply messaging policies Journal report decryption, to attach a decrypted copy of IRM-protected messages to journal reports AD RMS protection for Unified Messaging voice mail messages For more information about IRM features, see Information Rights Management.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

New Administrative Functionality in the Exchange Management Console

Exchange 2010 Applies to: Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 This topic describes the changes to the Exchange Management Console (EMC) in Microsoft Exchange Server 2010. Contents Feature Changes Core EMC Changes Exchange Help Need help finding features in the EMC? Check out Roadmap for Exchange Features.

Feature Changes
This section briefly describes the new features that have been added to the EMC.

New Features in the Organization Configuration Node

Database management has moved from the Server Configuration node to the Organization Configuration node. In addition, the following wizards have been added to the node:

New Federation Trust wizard Use this wizard to create a federation trust. A federation trust establishes a trust relationship between an Exchange organization and the Microsoft Federation Gateway. The trust is a prerequisite for enabling calendar free/busy sharing or federated delivery between two Exchange organizations, or allowing users to share their calendar and contacts with external recipients. For details, see Create a Federation Trust. New Organization Relationship wizard Use this wizard to create a relationship with an external Exchange 2010 organization for the purpose of sharing free/busy information, securing delivery of cross-premises e-mail using federated delivery, and moving mailboxes between on-premises Exchange servers and Microsoft Office Outlook Web App. For details, see Create an Organization Relationship. New Sharing Policy wizard Use this wizard to create a sharing policy to regulate how users inside your organization can share calendar and contact information with users outside the organization. For details, see Create a Sharing Policy. New Outlook Web App Mailbox Policy wizard Use this wizard to create an Outlook Web App mailbox policy to apply a common set of policy settings, such as attachment settings. Outlook Web App mailbox policies are useful for applying and standardizing settings for specific groups of users. For details, see Create Outlook Web App Mailbox Policy.

New Features in the Server Configuration Node

You can no longer manage mailbox or public folder databases from the Server Configuration node. Now, they're managed from the Organization Configuration node. However, you can view mailbox database properties (from the work pane of Server Configuration > Mailbox). In addition, the following features have been added to the node:

Manage Diagnostic Logging Properties wizard Use this wizard to modify the diagnostic logging level for processes used by Exchange 2010. Modifying these levels can help you troubleshoot issues that may occur in your organization. For details, see Manage Diagnostic Logging Levels. Exchange Certificates tab Use this tab to assign services to an Exchange certificate, remove or renew a certificate, or view the certificate's properties. For details, see the following topics: Assign Services to a Certificate Renew an Exchange Certificate View Exchange Certificate Properties New Exchange Certificate wizard Use this wizard tohelp you determine what type of certificates you need for the features in your organization to function correctly. For details, see Create a New Exchange Certificate. Import Exchange Certificate wizard Use this wizard to help import a certificate with a valid private key to a specified Exchange server. For details, see Import an Exchange Certificate.

New Features in the Recipient Configuration Node

The following features have been added to the Recipient Configuration node:

Send Mail Click this button to send mail to a recipient from the EMC. Before you can send mail, you need to set up an e-mail account on the computer from which you are sending mail. Resource scheduling The property pages for resource mailboxes now include tabs for configuring calendaring and scheduling. For details, see Configure User and Resource Mailbox Properties. Archive mailboxes You can enable or disable archive mailboxes directly from the EMC. In addition, you can manage the archive settings for users from the property page of their mailbox. For details, see Managing Archives. Move requests If you want to move mailboxes, you can use the New Local Move Request or New Remote Move Request wizards. You can also keep track of move requests that are in progress by using the Move Requests node. For details, see Managing Move Requests.

Core EMC Changes

The following new functionality affects how you use the EMC, but not how you use specific features. Expand each of these new feature sections to learn more.

Add Exchange Forests to the EMC Console Tree

You can now add Exchange forests to the EMC. The first forest will always be named Microsoft Exchange On-Premises. This is the default forest for your organization. You can add additional forests by using the Add Exchange Forest wizard. For details, see View Local Forest Properties.

Customer Experience Improvement Program

The Customer Experience Improvement Program (CEIP) collects anonymous information about how you use Exchange and the problems that you encounter. Microsoft uses this information to improve the products and features you use most often and to help solve problems. Participation in the program is voluntary, and the end results are software improvements to better meet your needs. For more information about the CEIP, see Microsoft Customer Experience Program FAQ. For details about how to opt-in or opt-out of the program, see Opt-in or Opt-out of the Customer Experience Improvement Program.

Organizational Health
The Organizational Health report lets you increase productivity by giving you a quick view of your organization and its operating characteristics. The report provides an organizational summary. This includes health and licensing information, and also a summary of Exchange servers and recipients. Important: This report is for information only. If errors occur while collecting the information, the report may not be accurate. Exchange doesn't automatically gather the organizational information. You must use the Collect Organizational Health Data wizard to view a summary of your organization's health. For details, see Collect Organizational Health Data.

Customer Feedback
The Customer Feedback tab is located in the result pane of the Microsoft Exchange On-Premises node. The tab is divided into two sections:

Customer Feedback Options This section allows you to run the Customer Experience Improvement Program wizard, which allows you to opt-in or out of the CEIP. For more information, see Opt-in or Opt-out of the Customer Experience Improvement Program. Help and Feedback This section provides a link to the Exchange Server TechCenter and allows you to submit feedback or to report bugs directly to the Exchange team.

Exchange Management Shell Command Log

The Exchange Management Shell Command Log records the commands that you execute in the EMC. For example, if you view the list of recipients from the Mailbox node, the Get-Recipient cmdlet is executed, and the Exchange Management Shell Command Log records that action. Note: The command log doesn't save the logging information. After you close the EMC, the log is erased. However, you can export the command log to tab-delimited or comma-delimited files. To view the command log, from the EMC toolbar, click View, and then click View Exchange Management Shell Command Log. For information about command logging, see Using the Exchange Management Shell Command Log to Track Tasks Performed in the EMC.

Property Dialog Command Exposure

Exposing the commands for actions executed in property pages allows you to see the Microsoft Windows PowerShell command and the parameters required to change object properties. To view the command, click the arrow icon located in the bottom left corner of the property page. To copy the command, select the command and press CTRL+C. Note: The command viewer is made available only after you make a property change.

Role Based Access Control in the EMC

When you open the EMC, Exchange checks to see what Role Based Access Control (RBAC) permissions you have. You can only view or configure features and items for which you have the correct permissions. If an administrator has permission to view an object but not edit it, the field text will appear dimmed and a caution icon will display. For more information about RBAC, see Understanding Role Based Access Control.

Exchange Help
The Exchange Help files are no longer downloaded to Exchange. Instead, they're hosted on Microsoft TechNet. This ensures that you're always viewing the most up-todate Help topics. Exchange 2010 contains two new cmdlets for managing Exchange Help:

Set-ExchangeAssistanceConfig Using this cmdlet, you can modify the URLs that the Exchange Help client uses to connect to the source of the Exchange 2010 documentation. By default, TechNet is used as the source. For details, see Set-ExchangeAssistanceConfig. Get-ExchangeAssistanceConfig Using this cmdlet, you can view the configuration information for the URLs that the Exchange Help client uses to connect to the source of the Exchange 2010 documentation. For details, see Get-ExchangeAssistanceConfig.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

New Exchange Core Store Functionality

Exchange 2010 Applies to: Exchange Server 2010 SP2 Topic Last Modified: 2012-02-28 Microsoft Exchange Server 2010 includes many improvements to the Exchange database architecture:

Public folder reporting has been enhanced. Databases are no longer associated with storage groups. Storage groups have been removed. Investments in store schema and Extensible Storage Engine (ESE) optimizations have reduced IOPS by 70 percent. The following sections describe these improvements in more detail. Contents Enhanced Reporting for Public Folders Database Management Store Schema Changes New ESE Functionality

Enhanced Reporting for Public Folders

Public folder reporting has been enhanced to view user-initiated changes to any item in the public folder. You can view this information by using the GetPublicFolderStatistics cmdlet in the Exchange Management Shell. For more information, see Exchange Management Shell.

Database Management
Databases are no longer associated with storage groups. In Exchange 2010, storage group functionality has been moved to the database. In Exchange 2010, you can manage mailbox and public folder databases in the Organization Configuration node of the EMC. (In Exchange Server 2007, database management was performed in the Server Configuration node.) Although public folder database management has been moved from the Server Configuration node to the Organization Configuration node with the mailbox databases, the functionality of public folder databases hasn't changed in Exchange 2010. Just like in Exchange 2007, you can't create database copies of public folder databases, and you can't add public folder databases to a database availability group (DAG). However, public folder databases can be hosted on Mailbox servers that are part of a DAG, although public folder databases won't be subject to log shipping or any other DAG features.

Database Cmdlet Changes

With the removal of storage groups in Exchange 2010, the storage group cmdlets used in Exchange 2007 were deleted and the Exchange 2010 database cmdlets now provide the functionality, as shown in the following tables.

Database cmdlets in Exchange 2010 that replace Exchange 2007 storage group cmdlets
Exchange 2007 cmdlet New-StorageGroup Description of functionality change in Exchange 2010

This cmdlet has been deleted, and configuration parameters were moved to the New-MailboxDatabase and NewPublicFolderDatabase cmdlets. This cmdlet has been deleted, and configuration parameters were moved to the Remove-MailboxDatabase and RemovePublicFolderDatabase cmdlets. This cmdlet has been deleted, and configuration parameters were moved to the Set-MailboxDatabase and the SetPublicFolderDatabase cmdlets. This cmdlet has been deleted, and configuration parameters were moved to the Get-MailboxDatabase and Get-PublicFolderDatabase cmdlets. This cmdlet has been deleted, and configuration parameters were moved to the Move-DatabasePath cmdlet.

RemoveStorageGroup Set-StorageGroup

Get-StorageGroup

MoveStorageGroupPath

Database cmdlets in Exchange 2010 that have extended functionality from Exchange 2007 cmdlets
Exchange 2010 cmdlet NewMailboxDatabase NewDescription of extended functionality in Exchange 2010

These cmdlets have been extended with the parameters and functionality from the New-StorageGroup cmdlet. They also update the server object with a link to the new database and the database object with the hosting server name.

PublicFolderDatabase RemoveMailboxDatabase RemovePublicFolderDatabase Set-MailboxDatabase SetPublicFolderDatabase Get-MailboxDatabase GetPublicFolderDatabase Move-DatabasePath These cmdlets have been extended with the parameters and functionality from the Remove-StorageGroup cmdlet. In addition, they also update the server object with the link to the new database and the database object with the hosting server name.

These cmdlets have been extended with the parameters and functionality from the Set-StorageGroup cmdlet. When changing the host servers, they also update the server object with the link to the new database and the database object with the hosting server name.

These cmdlets have been extended with the parameters and functionality from the Get-StorageGroup cmdlet. The Status parameter is extended to return the status information currently returned by the Get-StorageGroupCopyStatus cmdlet.

This cmdlet has been extended with the parameters and functionality from the Move-StorageGroupPath cmdlet.

In addition to the preceding cmdlet changes, the StorageGroupCopy cmdlets have been deleted. For more information, see Managing Mailbox Database Copies.

Store Changes
In Exchange 2010, the store schema has been changed to remove the dependency of mailbox databases on the server object. In addition, the new schema has been improved to help reduce database I/O per second (IOPS) by refactoring the tables used to store information. Refactoring the tables allows higher logical contiguity and locality of reference. These changes reduce the store's reliance on the secondary indexes maintained by ESE. As a result, the store is no longer sensitive to performance issues related to the secondary indexes. Store resilience and health has also been improved by adding several features related to detecting and correcting errors and providing alerts, such as the following:

Mailbox quarantine on rogue mailboxes Transport cutoff to databases with less than 1 GB of space Thread time-out detection and reporting For more information about store resilience and health, see Understanding the Exchange 2010 Store. Core store functionality has received many changes to improve high availability features. High availability has been integrated into the core architecture of Exchange 2010 to enable organizations of all sizes and in all industry segments to economically deploy a messaging continuity service. For more information about the high availability changes in Exchange 2010, see Understanding High Availability and Site Resilience.

New ESE Functionality

Extensible Storage Engine (ESE) has been improved in Exchange 2010 to achieve the following goals:

Larger I/O and sequential I/O to reduce IOPS Optimization for commodity storage Database management reduction Online defragmentation Online database scanning

Larger and Sequential I/O

By increasing the size of the I/O and reducing the frequency of read/writes in Exchange 2010, ESE is able to increase performance. In addition, ESE can increase performance by making the data in the database more sequential, which increases the likelihood that related data is in the same vicinity in the B-tree. In Exchange, all data inside the database is stored in B-trees, and the B-trees are then divided into pages. In Exchange 2007 and earlier, the data stored in the B-trees isn't contiguous. In fact, previous versions of Exchange performed random read/writes to the database. This means that related data may not be in the same vicinity on the hard disk. Non-contiguous data requires more passes to read and write to the hard disk.

B-Tree Defragmentation
The B-tree defragmentation process has been improved to reduce I/O operations by maintaining contiguous data in the B-tree. B-tree defragmentation is performed in-place (as opposed to creating a new B-tree and renaming the indexes and tables) with three new operations:

Page move A page move consists of moving all data from one page to a newly allocated page. Partial left merge A partial left merge is the same as a right merge in Exchange 2007 or earlier, except that data is moved from the left page to the right page. Full left merge A full left merge is the same as a full right merge in Exchange 2007 or earlier. Defragmentation has been changed from right merges to left merges to optimize performance. Data is read from or written to the hard disk from right to left. If the database is being defragmented in the same direction as the read/writes, defragmentation will conflict with the read/writes. In addition, space allocation allows the next page in an extent to be allocated, but not the previous page. Because a page move needs to allocate a new page, defragging the database from left to right is much more efficient. The Defragmentation Manager is a new event in ESE that monitors which B-trees require defragmenting and which B-trees have already been defragmented. The Defragmentation Manager compiles a list of the B-trees in all mounted databases that should be defragmented. As fragmented B-trees are discovered, they're registered with the Defragmentation Manager, and the Defragmentation Manager will process them.

Page Size Increase to 32 KB

All data inside the database is stored in B-trees, and the B-trees are divided into pages. The page size is the minimum size for reading and writing to the database; it's also the unit size used for database caching. Reading from the disk is slower than performing operations in memory; therefore, by increasing the page size to 32 KB, ESE reduces IOPS, which increases performance by caching the larger page size in memory.

Optimize for Commodity Storage

Another of the goals of ESE in Exchange 2010 is to reduce the capital and operational costs of deploying Exchange. This can be done by reducing storage costs and optimizing for commodity storage using JBOD and SATA class hard disks. Disk subsystems are more efficient at handling fewer but larger I/O. In Exchange 2010 or earlier, the page size is the minimum read/write size and the minimum size for database caching. Coalescing I/Os refers to the process of combining database page operations into a single I/O operation, thereby producing fewer and bigger I/O operations. Increasing the average database I/O sizes via coalescing I/Os has the following benefits:

Increased disk use efficiency Disks are more efficient at processing large I/Os. The more efficiently the disk is utilized, the more mailboxes can be hosted on that disk. Increased cache warming rate Cache warming is a process that helps reduce the execution times by preloading the initial queries that were executed against a database the last time the database was started. After a server restart, failover, or switchover, the larger I/O allows ESE to increase the rate at which the cache is warmed.

Database Maintenance
One of the goals of ESE in Exchange 2010 is to reduce the cost of maintaining and managing a database. Database maintenance is comprised of several tasks that manage and keep the integrity of your mailbox database. Database maintenance is divided into the following:

Store mailbox maintenance ESE database maintenance In Exchange 2007, ESE database maintenance was disk-intensive. In Exchange 2010, improvements have been made to increase performance. In Exchange 2010, on large or very heavy profile servers, the store mailbox maintenance task only lasts approximately 45 minutes, while ESE database maintenance usually took from six to eight hours per night to complete on large Exchange 2007 databases (2 GB quotas). In Exchange 2010, improvements have been made to support both large mailboxes as well as to support JBOD storage and storage without the use of RAID. Note: All Exchange Store-focused online database maintenance functions such as recovery item cleanup are the same in Exchange 2010 as they are in Exchange 2007. Only ESE functions, online defragmentation, and database checksumming have changed.

Database Defragmentation
Defragmentation makes the internal pages of an Exchange database contiguous. Defragmentation can either be performed automatically by the system while the database is online (online defragmentation) or manually by an administrator when the database is offline (offline defragmentation).

Online Defragmentation
In Exchange 2010, the architecture for online defragmentation has changed. Online defragmentation was moved out of the Mailbox database maintenance process. Online defragmentation now runs in the background 247. Because online defragmentation runs all the time, Exchange no longer posts events to the event log indicating the amount of white space in the database. During background database maintenance, items marked for removal from the database are removed, which frees up database pages. The percentage of white space is constantly changing due to the efforts of the continuous online defragmentation process. You can estimate the amount of white space in the database by knowing the amount of mail sent and received by the users with mailboxes in the database. For example, if you have 100 2-GB mailboxes (total of 200 GB) in a database where users send and receive an average of 10 MB of mail per day, the amount of white space is approximately 1 GB 100 mailboxes 10 MB per mailbox. The amount of white space can exceed this estimate if background database maintenance isn't able to complete a full pass. You don't need to configure any settings for this feature. Exchange monitors the database as it's being used, and small changes are made over time to keep it defragged for space and contiguity. If the database analyzes a range of pages and finds that they aren't as sequential as they should be, it starts an async thread to defragment that section of the B-tree/table. Online defragmentation is also throttled so it doesn't have a negative impact on client performance. Use the ESE performance counter set MSExchange Database ==> Defragmentation Tasks to see the tasks that are performed. For more information, see How to Enable Extended ESE Performance Counters.

Offline Defragmentation
Offline defragmentation is a manual process that is performed by an administrator while the database is in a dismounted (offline) state. In this process, the ESEUTIL tool is used to read the database file and write a new database file using the contents in a contiguous fashion. The offline defragmentation process doesnt copy

the white space from the original database; therefore, the size of the newly created database file is smaller than the original database on disk (potentially much smaller, depending on the amount of white space in the database). Historically, the typical reasons for performing an offline defragmentation of a database included the following:

To shrink the size of the database file on disk To reclaim white space in a database To avoid low free disk space To repair a damaged database (the second step in the repair following ESEUTIL /p) Offline defragmentation has never been part of regular maintenance for Exchange databases and, for some time now, Microsoft has recommended against regular, proactive offline defragmentation of databases. This recommendation was made for a variety of reasons, including the following:

It results in downtime because you have to take the database offline. In a replicated mailbox database environment, it results in the need to re-seed all passive copies of an active copy that has been defragmented offline, and it results in the need to re-seed any passive copy that has been defragmented offline. (Thus, you should never perform an offline defragmentation of a passive database copy.) It results in the creation of a new database, with a new database signature, and that eliminates the ability to restore log files from a backup of the database that was taken prior to offline defragmentation. As an alternative to offline defragmentation, we recommend that customers create a new database and move the mailboxes to the newly created database. In an Exchange 2010 environment, the mailboxes are moved online with no interruption in service to end users. In addition, when you move all mailboxes from an existing database to a new database, the end result is the same: A defragmented database with pages written contiguously and with no appreciable white space in the database file. After that process is complete, you simply delete the old (now empty) database. This guidance only covers proactive offline defragmentation to reclaim white space. You should still perform defragmentation if directed to do so by Microsoft Customer Support Services.

Online Database Scanning

Online database scanning (also known as database checksumming) has also changed. In Exchange 2007 Service Pack 1 (SP1), there was an option to use half of your online defragmentation time for this database scanning process (to ensure Exchange read every page from your database in a specific period of time to detect any corruptions). In Exchange 2010, online database scanning checksums the database and performs post Exchange 2010 Store crash operations. Space can be leaked due to crashes, and online database scanning finds and recovers lost space. The system in Exchange 2010 is designed with the expectation that every database is fully scanned once every seven days. A warning event is fired if a database isnt completely scanned in this timeframe. In Exchange 2010, there are now two modes to run online database scanning on active database copies:

Run as the last task in the scheduled Mailbox Database Maintenance process. You can configure how long it runs by changing the Mailbox Database Maintenance schedule. You can use this option for smaller databases that are less than 1 terabyte (TB) in size, which require less time to complete a full scan. Run in the background 247, the default behavior. This option works well for all database sizes, but its recommended for large database sizes 1-2 TB in size). Exchange scans the database no more than once per day. This read I/O is 100 percent sequential (which makes it easy on the disk) and equates to a scanning rate of about 5 megabytes (MB)/sec on most systems. For more information about configuring database maintenance, see Maintain Mailbox Databases.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

New High Availability and Site Resilience Functionality

Exchange 2010 Applies to: Exchange Server 2010 SP2 Topic Last Modified: 2011-07-11 Microsoft Exchange Server 2010 reduces the cost and complexity of deploying an e-mail solution that provides the highest levels of server availability and site resilience. Building on the native replication capabilities introduced in Exchange Server 2007, the new high availability architecture in Exchange 2010 provides a simplified, unified framework for both high availability and disaster recovery. Exchange 2010 integrates high availability into the core architecture of Exchange, enabling customers of all sizes and in all segments to be able to economically deploy a messaging continuity service in their organization.

Lessons Learned from Exchange Server 2007

Exchange 2007 decreased the costs of high availability and made site resilience much more economical by introducing new technologies such as local continuous replication (LCR), cluster continuous replication (CCR), and standby continuous replication (SCR). Still, some challenges remained:

Some administrators were intimidated by the complexity of Windows failover clustering. Achieving a high level of uptime can require a high level of administrator intervention. Each type of continuous replication was managed differently and separately. Recovering from a failure of a single database on a large Mailbox server could result in a temporary disruption of service to all users on the Mailbox server. Site resilience solutions were not seamless. The transport dumpster feature of the Hub Transport server could only protect messages destined for mailboxes in an LCR or CCR environment. If a Hub Transport server fails while processing messages and can't be recovered, it could result in data loss. Exchange 2010 includes significant core changes that integrate high availability deep in its architecture, making it even less costly and easier to deploy and maintain than Exchange 2007 for all customers. Organizations can now deploy a fully redundant Exchange organization with just two servers, and benefit from database-level failovers. Customers benefit from automatic, database-level failover capabilities without having to become experts in Windows failover clustering. Moreover, you can add site resilience to your existing high availability deployments with less complexity. Exchange 2007 introduced many new architectural changes designed to make deploying high availability and site resilience solutions for Exchange faster and simpler. These improvements included an integrated Setup experience, optimized out-of-box configuration settings, and the ability to manage most aspects of the high availability solution using native Exchange management tools. Still, management of an Exchange 2007 high availability solution required administrators to master some clustering concepts, such as the concept of moving network identities and managing cluster resources. In addition, when troubleshooting issues related to a clustered Mailbox server, administrators had to use Exchange tools and cluster tools to review and correlate logs and events from two different sources: one from Exchange and one from the cluster. Two other limiting aspects of the Exchange 2007 architecture have also been re-evaluated and re-engineered based on customer feedback:

Clustered Exchange 2007 servers require dedicated hardware. Only the Mailbox server role could be installed on a node in the cluster. This meant that a minimum of four Exchange servers were required to achieve full redundancy of the primary components of a deployment, that is, the core server roles (Mailbox, Hub Transport, and Client Access). In Exchange 2007, failover of a clustered Mailbox server occurs at the server level. As a result, if a single database failure occurred, the administrator had to fail over the entire clustered Mailbox server to another node in the cluster (which resulted in brief downtime for all users on the server, and not just those users with a mailbox on the affected database), or leave the users on the failed database offline (potentially for hours) while restoring the database from backup.

Mailbox Resiliency
Exchange 2010 has been re-engineered around the concept of mailbox resiliency, in which the architecture has changed so that automatic failover protection is now provided at the individual mailbox database level instead of at the server level. In Exchange 2010, this is known as database mobility. As a result of this and other database cache architectural changes, failover actions now complete much faster than in previous versions of Exchange. For example, failover of a clustered Mailbox server in a CCR environment running Exchange 2007 with Service Pack 2 (SP2) completes in about two minutes. By comparison, failover of a mailbox database in an Exchange 2010 environment completes in 30 seconds or less (measured from the time when the failure is detected to when a database copy is mounted, assuming an available copy that's healthy and up to date with log replay). The combination of database-level failovers and significantly faster failover times dramatically improves an organization's overall uptime. The mailbox resiliency architecture built into Exchange 2010 provides new benefits for organizations and their messaging administrators:

Multiple server roles can coexist on servers that provide high availability. This enables small organizations to deploy a two-server configuration that provides redundancy of mailbox data and service, while also providing redundant Client Access and Hub Transport services. An administrator no longer needs to build a failover cluster to achieve high availability. Failover clusters are now created by Exchange 2010 in a way that's invisible to the administrator. Unlike previous versions of Exchange clusters which used an Exchange-provided cluster resource DLL named ExRes.dll, Exchange 2010 no longer needs or uses a cluster resource DLL. Exchange 2010 isn't a clustered application, and it uses only a small portion of the failover cluster components, namely, its heartbeat capabilities and the cluster database, to provide database mobility. Administrators can add high availability to their Exchange 2010 environment after Exchange has been deployed, without having to uninstall Exchange and then redeploy in a highly availability configuration. Exchange 2010 provides a view of the event stream that coalesces and combines the events from the operating system with the events from Exchange. Because storage group objects no longer exist in Exchange 2010, and because mailbox databases are portable across all Exchange 2010 Mailbox servers, it's easy to move databases when needed. For more information, see High Availability and Site Resilience.

Flexible Mailbox Protection

Exchange 2010 includes several new features and core changes that, when deployed and configured correctly, can provide flexible mailbox protection that eliminates the need to make traditional backups of your data. Using the high availability features built into Exchange 2010 to minimize downtime and data loss in the event of a disaster can also reduce the total cost of ownership of the messaging system. By combining these features with other built-in features, such as Legal Hold, organizations can reduce or eliminate their dependency on traditional point-in-time backups and realize the cost savings of doing so. In addition to determining whether Exchange 2010 enables you to move away from traditional point-in-time backups, we also recommend that you evaluate the cost of your current backup infrastructure. Consider the cost of end-user downtime and data loss when attempting to recover from a disaster using your existing backup infrastructure. Also, include hardware, installation and license costs, as well as the management cost associated with recovering data and maintaining the backups. Depending on the requirements of your organization, it is quite likely that a pure Exchange 2010 environment with at least three mailbox database copies will provide lower total cost of ownership than one with backups. For more information about flexible mailbox protection, see Understanding Backup, Restore and Disaster Recovery.

Changes to High Availability from Previous Versions of Exchange

Exchange 2010 includes many changes to its core architecture. Exchange 2010 combines the key availability and resilience features of CCR and SCR into single high availability solution which handles both onsite data replication and offsite data replication. Mailbox servers can be defined as part of a database availability group (DAG) to provide automatic recovery at the individual mailbox database level instead of at the server level. Each mailbox database can have up to 16 copies. Other new high availability concepts are introduced in Exchange 2010, such as database mobility and incremental deployment. The concepts of an organization without backups and RAID are also being introduced in Exchange 2010. To summarize, the key aspects to data and service availability for the Mailbox server role and mailbox databases are:

Exchange 2010 uses an enhanced version of the same continuous replication technology introduced in Exchange 2007. For more information, see Changes to Continuous Replication from Exchange Server 2007 later in this topic. Storage groups no longer exist in Exchange 2010. Instead, there are simply mailbox databases, mailbox database copies, and public folder databases. The primary management interfaces for Exchange databases has moved within the Exchange Management Console from the Mailbox node under Server Configuration to the Mailbox node under Organization Configuration. Some Windows Failover Clustering technology is used by Exchange 2010, but it's now completely managed by Exchange. Administrators don't need to install, build, or configure any aspects of failover clustering when deploying highly available Mailbox servers. Each Mailbox server can host as many as 100 databases, and each database can have as many as 16 copies. In addition to the transport dumpster feature, a new Hub Transport server feature named shadow redundancy has been added. Shadow redundancy provides redundancy for messages for the entire time they're in transit. The solution involves a technique similar to the transport dumpster. With shadow redundancy, the deletion of a message from the transport database is delayed until the transport server verifies that all of the next hops for that message have completed delivery. If any of the next hops fail before reporting back successful delivery, the message is resubmitted for delivery to that next hop. For more information about shadow redundancy, see Understanding Shadow Redundancy.

Incremental Deployment
In previous versions of Exchange, service availability for the Mailbox server roles was achieved by deploying Exchange in a Windows failover cluster. To deploy Exchange in a cluster, you had to first build a failover cluster, and then install the Exchange program files. This process created a special Mailbox server called a clustered Mailbox server (or Exchange Virtual Server in previous versions of Exchange). If you had already installed the Exchange program files on a non-clustered server and you decided you wanted a clustered Mailbox server, you had to build a cluster using new hardware, or remove Exchange from the existing server, install failover clustering, and reinstall Exchange. Exchange 2010 introduces the concept of incremental deployment, which enables you to deploy service and data availability for all Mailbox servers and databases after Exchange is installed. Service and data redundancy is achieved by using new features in Exchange 2010 such as DAGs and database copies.

Database Availability Groups

A DAG is a set of up to 16 Mailbox servers that provide automatic database-level recovery from failures that affect individual databases. Any server in a DAG can host a copy of a mailbox database from any other server in the DAG. When a server is added to a DAG, it works with the other servers in the DAG to provide automatic recovery from failures that affect mailbox databases, such as a disk failure or server failure. For more information about DAGs, see Understanding Database Availability Groups.

Mailbox Database Copies

The high availability and site resilience features first introduced in Exchange 2007 are used in Exchange 2010 to create and maintain database copies, thereby enabling you to achieve your availability goals in Exchange 2010. Exchange 2010 also introduces the new concept of database mobility, which is Exchange-managed databaselevel failovers. Database mobility disconnects databases from servers, adds support for up to 16 copies of a single database, and provides a native experience for adding database copies to a database. In Exchange 2007, a feature called database portability also enabled you to move a mailbox database between servers. A key distinction between database portability and database mobility, however, is that with database mobility, all copies of a database have the same GUID. Other key characteristics of database mobility are:

Because storage groups have been removed from Exchange 2010, continuous replication now operates at the database level. In Exchange 2010, transaction logs are replicated to one or more Mailbox servers and replayed into a copy of a mailbox database that's stored on those servers. A failover is an automatic activation process that can occur at either the database level or at the server level. A switchover is a manual activation process that you can perform at the database, server, or data center (site) level. Database names for Exchange 2010 must be unique within the Exchange organization. When a mailbox database has been configured with one or more database copies, the full path for all database copies must be identical on all Mailbox servers that host a copy. Any mailbox database copy (the active or any passive copy) can be backed up using an Exchange-aware Volume Shadow Copy Service (VSS)-based backup

application. For more information about mailbox database copies, see Understanding Mailbox Database Copies.

Changes to Continuous Replication from Exchange Server 2007

The underlying continuous replication technology previously found in CCR and SCR remains in Exchange 2010, and it's been further evolved to support new high availability features such as database copies, database mobility, and DAGs. Some of these new architectural changes are briefly described as follows:

Because storage groups have been removed from Exchange 2010, continuous replication now operates at the database level. Exchange 2010 still uses an Extensible Storage Engine (ESE) database that produces transaction logs that are replicated to one or more other locations and replayed into one or more copies of a mailbox database. Because the log replay functionality that was performed by the Microsoft Exchange Replication service in Exchange 2007 has been moved into the Exchange 2010 version of the Microsoft Exchange Information Store service (store.exe), the performance hit associated with failovers and switchovers (because a new database cache was put into use) no longer exists. When a failover or switchover occurs, the activated database has a warm cache that's ready for use. Log shipping and seeding no longer uses Server Message Block (SMB) for data transfer. Exchange 2010 continuous replication uses a single administratordefined TCP port for data transfer. In addition, Exchange 2010 includes built-in options for network encryption and compression for the data stream. Log shipping no longer uses a pull model, where the passive copy pulls closed log files from the active copy. Instead, the active copy pushes the log files to each configured passive copy. Seeding is no longer restricted to using only the active copy of the database. Passive copies of mailbox databases can now be specified as sources for database copy seeding and reseeding. Database copies are for mailbox databases only. For redundancy and high availability of public folder databases, we recommend that you use public folder replication. Unlike CCR, where multiple copies of a public folder database couldn't exist in the same cluster, each DAG member can host a public folder database, and you can use public folder replication to replicate public folders between public folder databases hosted on DAG members. The LogReplayer component of the Microsoft Exchange Replication service includes new logic to suspend log replay if the copy queue length increases beyond a specific threshold. If the number of logs in the copy queue is greater than the number of log files that have been copied to the passive database copy, but not inspected by the passive copy, then the Microsoft Exchange Replication service will suspend log replay for the passive copy and log Warning event 4110 in the event log. When the number of log files in the copy queue drops below the number of non-inspected copied log files, the Microsoft Exchange Replication service will resume replay for the passive copy and log Informational event 4111 in the event log. Several concepts used in Exchange 2007 continuous replication also remain in Exchange 2010. These include the concepts of failover management, divergence, the use of the auto database mount dial, and the use of public and private networks.

Changes to Routing Behavior When Hub Transport and Mailbox are Co-Located in a DAG
When the Hub Transport server is co-located with a Mailbox server that is a member of a DAG, there are changes in routing behavior to ensure that the resiliency features in both server roles will provide the necessary protection for messages sent and received by users on that server. The Hub Transport server role was modified so that it now attempts to re-route a message for a local Mailbox server to another Hub Transport server in same site if the Hub Transport server is also a DAG member and it has a copy of the mailbox database mounted locally. This extra hop was added in order to put the message in transport dumpster on a different Hub Transport server. For example, EX1 hosts the Hub Transport and Mailbox role and is a member of a DAG. When a message arrives in transport for EX1 that is destined for a recipient whose mailbox is also on EX1, transport will re-route the message to another Hub Transport server in the site (for example, EX2), and that server will deliver the message to the mailbox on EX1. There is a second similar behavior change with respect to the Microsoft Exchange Mail Submission service. This service was modified so that it would prefer to not submit messages to a local Hub Transport role when the Mailbox and Hub Transport server is a member of a DAG. In this scenario, the behavior of transport is to load balance submission requests across other Hub Transport servers in same Active Directory site, and fall back to local Hub Transport server if there are no other available Hub Transport servers in the same site.

End-to-End Availability
Exchange 2010 also includes many features designed to increase end-to-end availability of the system. These features include:

Transport resilience Online move mailbox Exchange native data protection Incremental resync Third Party Replication API

Transport Resilience
Exchange 2007 introduced the transport dumpster feature of the Hub Transport server. The transport dumpster maintains a queue of messages that were delivered to recipients whose mailbox was in a CCR (and in Exchange 2007 SP1, in an LCR) environment. This feature was designed to help protect against data loss by providing an administrator with the option to have a clustered Mailbox server automatically come online on another node with a limited amount of data loss. This is referred to as a lossy failover. When a lossy failover occurred, the system automatically re-delivered the recent e-mail messages sent to users on the failed clustered Mailbox server, by using the transport dumpster where the e-mail messages were still stored. Although this solution helped to minimize the amount of data lost in a lossy failover, the solution only protected from data loss within a site, and it didn't provide protection for messages in transit. Exchange 2010 introduces core architectural changes that address both issues. Because DAGs can be stretched across Active Directory sites, it's possible for an individual mailbox database to move between Active Directory sites. Because of this design change, the transport dumpster re-delivery request upon a lossy database failover is now issued to Hub Transport servers in both the database's original and new Active Directory sites. One other significant change to the transport dumpster is that it now receives feedback from the replication pipeline. When messages in the transport dumpster have been replicated to all mailbox database copies, they're removed from the transport dumpster. This ensures that only non-replicated data is held in the transport dumpster. In addition to the transport dumpster feature, a new Hub Transport server feature named shadow redundancy has been added. Shadow redundancy provides

redundancy for messages for the entire time they're in transit. The solution involves a technique similar to the transport dumpster. With shadow redundancy, the deletion of a message from the transport database is delayed until the transport server verifies that all of the next hops for that message have completed delivery. If any of the next hops fail before reporting back successful delivery, the message is resubmitted for delivery to that next hop. For more information about shadow redundancy, see Understanding Shadow Redundancy.

Online Move Mailbox

Exchange 2010 includes a new feature that enables you to move mailboxes asynchronously. In Exchange 2007, when you used the Move-Mailbox cmdlet to move a mailbox, the cmdlet logged into both the source database and the target database and moved the content from one mailbox to the other mailbox. There were several disadvantages to having the cmdlets perform the move operation:

Mailbox moves typically took hours to complete, and during the move, users weren't able to access their mailbox. If the command window used to run Move-Mailbox cmdlet was closed, the move was terminated and had to be restarted from the beginning. The computer used to perform the move participated in the data transfer. If an administrator ran the cmdlets from their workstation, the mailbox data would flow from the source server to the administrator's workstation and then to the target server. The new move request cmdlets in Exchange 2010 can be used to perform asynchronous moves. Unlike Exchange 2007, the cmdlets don't perform the actual move. The move is performed by the Microsoft Exchange Mailbox Replication Service, a new service that runs on the Client Access server. The New-MoveRequest cmdlet sends requests to the Mailbox Replication Service. For more information about online move mailbox, see Understanding Move Requests.

Exchange Native Data Protection

There are several changes to the core architecture of Exchange 2010 that have a direct effect on how you protect your mailbox databases and the mailboxes they contain. One significant change is the removal of storage groups. In Exchange 2010, each database is associated with a single log stream, represented by a series of 1 megabyte (MB) log files. Each server can host a maximum of 100 databases. Another significant change for Exchange 2010 is that databases are no longer closely tied to a specific Mailbox server. Database mobility expands the system's use of continuous replication by replicating a database to multiple different servers. This provides better protection of the database and increased availability. In the case of failures, the other servers that have copies of the database can mount the database. The ability to have multiple copies of a database hosted on multiple servers, means that if you have a sufficient number of database copies, you can use these copies as your backups. For more information on this strategy, see Understanding Backup, Restore and Disaster Recovery.

Incremental Resync
Exchange 2007 introduced the concepts of lost log resilience (LLR) and incremental reseed. LLR is an internal component of ESE that enables you to recover Exchange mailbox databases even if one or more of the most recently generated transaction log files have been lost or damaged. LLR enables a mailbox database to mount even when recently generated log files are unavailable. LLR works by delaying writes to the database until the specified number of log generations have been created. LLR delays recent updates to the database file for a short time. The length of time that writes are delayed depends on how quickly logs are being generated. Note: LLR is hard-coded to one log file for all Exchange 2010 mailbox databases. Incremental reseed provided the ability to correct divergences in the transaction log stream between a source and target storage group, by relying on the delayed replay capabilities of LLR. Incremental reseed didn't provide a means to correct divergences in the passive copy of a database after divergent logs had been replayed, which forced the need for a complete reseed. In Exchange 2010, incremental resync is the new name for the feature that automatically corrects divergences in database copies under the following conditions:

After an automatic failover for all of the configured copies of a database When a new copy is enabled and some database and log files already exist at the copy location When replication is resumed following a suspension or restarting of the Microsoft Exchange Replication Service When divergence between an active database and a copy of that database is detected, incremental resync performs the following tasks:

It searches historically in the log file stream to locate the point of divergence. It locates the changed database pages on the diverged copy. It reads the changed pages from the active copy and then copies the necessary log files from the active copy. It applies the database page changes to the diverged copy. It runs recovery on the diverged copy and replays the necessary log files into the database copy.

Third Party Replication API

Exchange 2010 also includes a new Third Party Replication API that enables organizations to use third-party synchronous replication solutions instead of the built-in continuous replication feature. For information about partner products for Exchange 2010, see the Exchange 2010 Partners Web site. If you're a partner seeking information on the Third Party Replication API, please contact your Microsoft representative.

Features Cut from Exchange Server 2007

The following features in Exchange 2007 and Exchange 2007 SP1 no longer exist in Exchange 2010. Their replacements are noted in the table.

Feature Cluster continuous replication (CCR) Standby continuous replication (SCR) Local continuous replication (LCR) Single copy clusters (SCC)

Replacement Database availability groups and mailbox database copies

Database availability groups and mailbox database copies

Database availability groups and mailbox database copies

Database availability groups and mailbox database copies; built-in third-party synchronous API available to replace third-party data replication used with SCC Database availability groups and mailbox database copies Databases Recovery database

Clustered Mailbox servers Storage groups Recovery Storage Group

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

New Messaging Policy and Compliance Functionality

Exchange 2010 Applies to: Exchange Server 2010 SP2 Topic Last Modified: 2011-12-01 Microsoft Exchange Server 2010 has new messaging policy and compliance features that allow organizations to comply with regulations related to messaging retention, protection of personal information, and fulfilling legal discovery requests for messaging records. Contents Messaging Records Management Multi-Mailbox Search Litigation Hold Information Rights Management Protection Personal Archive Transport Rule Predicates and Actions

Messaging Records Management

Messaging records management (MRM) is the records management technology in Exchange that helps organizations to reduce legal risks associated with e-mail and other communications. In Exchange 2010, MRM is accomplished by using the following new retention features:

Retention tags Retention tags are used to apply retention settings to messages and folders. There are three types of retention tags: Default policy tags (DPTs) Retention policy tags (RPTs) Personal tags Retention policies A retention policy is a group of retention tags that can be applied to a mailbox. Applying retention policies to the mailboxes in your organization allows you to apply message retention settings without impacting your users' e-mail workflow or e-mail organization methods. Also, with retention tags, users can tag messages and folders based on retention requirements. They no longer need to move messages to folders only for retention purposes (as was required by the managed folders feature in Exchange Server 2007). Note: Managed folders, the MRM technology introduced in Exchange 2007, is still available in Exchange 2010. For more information, see Understanding Managed Folders. To learn more about the retention features in Exchange 2010, see Understanding Retention Tags and Retention Policies. Return to top

Multi-Mailbox Search
In Exchange 2010, Multi-Mailbox Search helps organizations facing legal discovery requirements (as part of organizational policy, compliance requirements, or lawsuits), to search for relevant content in Exchange mailboxes. Exchange 2010 provides a seamless experience for searching e-mail content in mailboxes across the entire Exchange organization. To learn more about Multi-Mailbox Search, see Understanding Multi-Mailbox Search. Return to top

Litigation Hold
In Exchange 2010, Multi-Mailbox Search allows a user who is assigned the Discovery Management role to search mailbox content to comply with discovery requests. However, users who own the mailbox or have permissions to access it can delete messages. Furthermore, if a retention policy or a managed folder mailbox policy is applied to the mailbox, messages can be removed from the mailbox by the Managed Folder Assistant. In Exchange 2010, you can place mailboxes on litigation hold to protect against intentional, policy-based, or accidental message deletion. This allows deleted messages to be indexed by Exchange Search. As a result, these messages are returned when Multi-Mailbox Search is used to search the mailbox. After a mailbox is placed on litigation hold, any changes made to messages are also preserved as different versions. To learn more about litigation hold, see Understanding Litigation Hold. Return to top

Information Rights Management Protection

Protecting critical business information is an important aspect of information protection. Regulations in many countries, regions, and industries (such as financial services

and healthcare), require organizations to protect personal information collected from customers and employees. Most business communication occurs over e-mail, and many users also use e-mail as an information and document repository. To help protect this critical information, Exchange 2010 includes the following Information Rights Management (IRM) features:

Support for Active Directory Rights Management Services (AD RMS) rights policy templates. Persistent protection of attachments in IRM-protected messages. Outlook protection rules protect messages in Microsoft Outlook 2010 based on rule conditions. Transport protection rules protect messages based on transport rule conditions. Transport decryption decrypts IRM-protected messages on Hub Transport servers, which allows you to apply messaging policies. Journal report decryption attaches a decrypted copy of IRM-protected messages to journal reports. Support for IRM in Microsoft Office Outlook Web App. IRM-protection for Unified Messaging voice mail messages. To learn more about IRM features, see Understanding Information Rights Management. Return to top

Personal Archive
Personal archives provide your users with an alternate storage location for storing historical messaging data. Using Outlook 2010 and Outlook Web App, users have seamless access to their personal archive. Using either of these client applications, they can view a personal archive and move or copy messages between their primary mailbox and the archive. Messages can also be automatically moved from the primary mailbox to the archive by using an archive policy. Personal archives allow you to present your users with a consistent view of their messaging data, and they also eliminate the user overhead required to manage .pst files. Eliminating use of .pst files significantly reduces your organization's exposure to several risks. To learn more about personal archives, see Understanding Personal Archives. Return to top

Transport Rule Predicates and Actions

Transport rules inspect messages for conditions specified in the rule. Messages that meet the conditions, and none of the exceptions, have the specified actions applied to them. Exchange 2010 includes several new predicates and actions, providing additional flexibility when creating rules. To learn more, see Transport Rule Predicates and Transport Rule Actions. The New-TransportRule and Set-TransportRule cmdlets are also enhanced, allowing you to specify all predicates and actions in a single command. All predicates and actions are now available for use as parameters with these cmdlets. To learn more about these cmdlets, see New-TransportRule and Set-TransportRule. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

New Unified Messaging Functionality and Voice Mail Features

Exchange 2010 Applies to: Exchange Server 2010 SP2 Topic Last Modified: 2010-08-19 New functionality and many new features have been added to Microsoft Exchange Server 2010 Unified Messaging (UM). This topic explains the new features for Unified Messaging and voice mail that are included in Exchange 2010. Contents Call Answering Rules Additional Language Support Improvements to Name Lookup from a Caller ID Voice Mail Preview Message Waiting Indicator Missed Call and Voice Mail Notifications Using SMS Protected Voice Mail Incoming Fax Support Group Addressing Using Outlook Voice Access Built-in Unified Messaging Administrative Roles

Call Answering Rules

In Exchange 2010, the Unified Messaging server role allows UM-enabled users to create and customize call answering rules to enhance the experience of people who call them. At the time a user becomes enabled for UM, no call answering rules exist. The Exchange 2010 voice mail is the default call answering behavior. However, users can create up to nine call answering rules. Call answering rules are similar to the Exchange Server 2007 UM auto attendants. There is usually a greeting, a menu prompt, and a list of options to choose from. The key difference between an auto attendant and a call answering rule that, when the call answering rule processes an incoming call, Unified Messaging already knows who the call is for. Using call answering rules, a caller can:

Leave a voice message for the UM-enabled user. Transfer to an alternate contact of the UM-enabled user. Transfer to the alternate contact's voice mail. Transfer to other phone numbers that the UM-enabled user has configured. Use the Find-Me feature or locate the UM-enabled user via a supervised transfer.

Additional Language Support

In Exchange 2007, each UM language pack included a Text-to-Speech (TTS) engine and the prerecorded prompts for a specified language. UM language packs for Exchange 2007 are offered in 16 different languages. However, not all the UM language packs contain support for Automatic Speech Recognition (ASR). For ASR, there was only one languageUS English. For Exchange 2010, all available language packs contain the Text-to-Speech (TTS) engine and the prerecorded prompts for a specified language and ASR support. However, only some of the language packs contain support for Voice Mail Preview. The US English (en-US) language pack is included on the Exchange 2010 DVD and additional UM language packs can be downloaded from the Microsoft Download Center. For more information about UM language packs, see the following topics:

Client Language Support for Unified Messaging Understanding Unified Messaging Languages

Improvements to Name Lookup from a Caller ID

In Exchange 2007 Unified Messaging, a voice message was created after a call was diverted to a Unified Messaging server because of a ring-no-answer or busy condition. After the call was answered, Exchange 2007 Unified Messaging tried to resolve the caller ID. It did this so that it could insert a name, rather than a number, into the sender information. In Exchange 2007, name lookups for voice mail messages were done using information about the caller who was in the same dial plan as the user being called. Name lookups were performed by using an Exchange Unified Messaging proxy address (EUM proxy address), using the personal contacts of the user receiving the call, or using the msRTCSIP-Line attribute in Active Directory if Service Pack 1 (SP1) for Exchange 2007 was installed and Exchange 2007 was integrated with Office Communications Server 2007.

In Exchange 2010, the name lookup methods used in Exchange 2007 have been enhanced. Although Exchange 2010 includes methods that were used to resolve calling IDs in Exchange 2007, eight other Active Directory attributes have been added for resolving a caller ID to a name. You can use the following steps to look up a name from the calling party's information:

1. Use the caller's name if the caller is signed in to their mailbox from Outlook Voice Access or if they use a Unified Communications client such as Office Communicator 2007 or Office Communicator Phone Edition to place the call. The caller's identity is known because they've already been authenticated by Outlook Voice Access, Office Communicator 2007 or Office Communicator Phone Edition. 2. Use the EUM proxy addresses in Active Directory. If the proxy address contains an at sign (@), it's considered to be a Session Initiation Protocol (SIP) Uniform Resource Identifier (URI). If the proxy address begins with a plus sign (+), it's considered to be an E.164 number. If neither of these symbols is present, the address is considered to be an extension within the same dial plan as the called party or an equivalent dial plan. 3. If the caller ID is a valid SIP URI, use Active Directory to resolve the SIP URI using the EUM proxy addresses. 4. If the caller ID is a valid E.164 number, use Active Directory to resolve the number using the calling party's name. For this to work correctly, you must manually configure the UMCallingLineIds parameter on the UM-enabled mailbox for each user. This is useful when you don't want to publish a telephone number, such as a personal cell phone number, in Active Directory, but still want to resolve the calling party's name by using this phone number. 5. Use Active Directory heuristic matching, if it is enabled, to resolve the number using the calling party's name. Active Directory heuristic matching must be enabled on the dial plan, and the user's account in Active Directory must contain information in at least one of the following Active Directory attributes: a. TelephoneNumber b. HomePhone c. Mobile d. FacsimileTelephoneNumber e. OtherTelephone f. OtherHomePhone g. OtherMobile h. OtherFacsimileTelephoneNumber 6. Use the personal Contacts of the called party to resolve the number using the calling party's name. 7. If the calling party's name is not resolved using one the methods described previously, the phone number is used in the voice mail message.

Voice Mail Preview

In Exchange 2010, the Unified Messaging server role uses ASR on newly created voice mail messages. When users receive voice messages, the messages contain both a recording and text that's been created from the voice recording. Users see the voice message text displayed in an e-mail message from within Outlook Web App, Outlook 2007, or Outlook 2010.

Message Waiting Indicator

Message Waiting Indicator is a feature found in most legacy voice mail systems and can refer to any mechanism that indicates the existence of a new message. In Exchange 2007, this functionality was provided by a third-party application, which indicated receipt of a new voice message by lighting the lamp on the desk phone. This feature has been added to Exchange 2010, and third-party software isn't needed. Enabling or disabling Message Waiting Indicator is done on the user's mailbox or on a UM mailbox policy.

Missed Call and Voice Mail Notifications Using SMS

When users are members of a hosted or consumer dial plan, and they configure their voice mail settings with their mobile phone number and configure call forwarding, they can receive notifications about missed calls and new voice messages on their cell phones in a text message via the Short Messaging Service (SMS). However, to receive these types of notifications, the users must first configure text messaging and also enable Notifications on their account.

Protected Voice Mail

Protected Voice Mail is Unified Messaging functionality that enables users to send private mail. This mail is protected by Active Directory Rights Management Services (AD RMS), and users are restricted from forwarding, copying, or extracting the voice file from e-mail. Protected Voice Mail increases the confidentiality of Unified Messaging, and lets users rely on Unified Messaging if they want to limit the audience for voice messages. This functionality is similar to the way private e-mail messages were handled in Exchange 2007. In Exchange 2010, it applies to voice mail messages as well.

Incoming Fax Support

Exchange 2007 provided built-in support for fax message creation through the Unified Messaging server role. A user with a UM-enabled mailbox could receive fax messages from calls placed to his or her phone number. There's no support in Exchange 2007 UM for inbound fax routing, or for outgoing fax. In Exchange 2010, direct support for fax has been removed from the Unified Messaging server role. Customers who require a fax solution that works with Exchange 2010 will need to deploy a fax partner solution. Fax partner solutions are available from several fax partners. The fax partner solutions are designed to be tightly integrated with Exchange 2010 and allow UM-enabled users to receive incoming fax messages.

Group Addressing Using Outlook Voice Access

In Exchange 2007, users could use either the telephone user interface (TUI) or voice user interface (VUI) in Outlook Voice Access to send e-mail and voice messages when they logged on to their mailbox. However, users could only send a single e-mail message to a single user in their personal Contacts, to multiple recipients from the directory by adding each recipient individually, or by adding the name of a distribution list from the global address list. In Exchange 2010, when a user signs in to their mailbox using Outlook Voice Access, they can also send e-mail and voice messages to users in a group stored in their personal Contacts.

Built-in Unified Messaging Administrative Roles

A set of roles for managing Unified Messaging and voice mail features have been defined within Exchange 2010. Administrative roles that included UM were available in Exchange 2000. The following UM-specific administrative roles have been added for Exchange 2010:

UM Mailboxes UM Prompts Unified Messaging

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

New Mailbox and Recipient Functionality

Exchange 2010 Applies to: Exchange Server 2010 SP2 Topic Last Modified: 2009-12-07 This topic lists the new functionality available for Mailbox servers, mailboxes, and recipients in Microsoft Exchange Server 2010. For information about the other mailbox features, see the following topics:

New Exchange Core Store Functionality New High Availability and Site Resilience Functionality Contents

Calendaring Calendar Repair Assistant Resource Scheduling Moving Mailboxes Distribution Groups Permission Management for Mailbox Folders Bulk Recipient Management in the EMC Personal Archive Send Mail

Calendaring

In Exchange 2010, your users can share information with external users. This information includes calendar, contacts, and free/busy data. For more information about accessing free/busy data from different organizations, see Managing Federated Delegation. Note: Contact sharing will be available with the release of Microsoft Outlook 2010. For information about when Outlook 2010 will be available, visit Microsoft Office Online. Before you can share any information between organizations, a federation trust must be established. For more information, see Federation. The MailboxCalendarSettings commands have been removed. The functionality is replaced by the following cmdlets:

Get-MailboxCalendarConfiguration Set-MailboxCalendarConfiguration Get-CalendarProcessing Set-CalendarProcessing Return to top

Calendar Repair Assistant

Calendar Repair Assistant (CRA) is a configurable, time-based mailbox assistant that runs within the Microsoft Exchange Mailbox Assistants service on Exchange 2010 Mailbox servers. CRA automatically detects and corrects inconsistencies for single and recurring meeting items in mailboxes. With this functionality, recipients won't miss meetings or have unreliable meeting information. For more information about CRA, see Understanding Calendar Repair. Return to top

Resource Scheduling
You can now use the Exchange Management Console (EMC) to manage resource scheduling by editing the resource mailbox's properties. For more information, see Configure User and Resource Mailbox Properties. Return to top

Moving Mailboxes
Exchange 2010 includes cmdlets that allow you to move a mailbox while the end user is still accessing it. These cmdlets are for use in moving Exchange 2010 mailboxes between Exchange 2010 databases. Use the Move-Mailbox cmdlet in Exchange Server 2007 to move legacy Exchange mailboxes. For more information, see Understanding Move Requests or Managing Move Requests.

Mailbox moves are now managed by the following cmdlets:

New-MoveRequest This cmdlet begins the process to move a mailbox. You can test the readiness of a mailbox by including the WhatIf parameter in the command. Get-MoveRequest This cmdlet retrieves statistics about the status of an ongoing mailbox move that was initiated by using the New-MoveRequest cmdlet. Remove-MoveRequest This cmdlet cancels an ongoing mailbox move that was initiated by using the New-MoveRequest cmdlet. Return to top

Distribution Groups
Exchange 2010 includes new functionality for both moderated and user-created distribution groups.

Moderated Distribution Groups

You can appoint a moderator to regulate the flow of messages sent to a distribution group. Anyone can send a message to the distribution group alias, but before the message is delivered to all participants, a moderator must review and approve it. This helps prevent inappropriate e-mail messages from being delivered to large audiences. For more information, see Understanding Moderated Transport.

User-Created Distribution Groups

The following is a list of new functionality for user-created distribution groups:

New parameters have been added to the distribution group cmdlets to allow users to create and manage their own distribution groups in Microsoft Office Outlook Web App and Outlook 2010. A new user interface (UI) has been added to allow administrators to manage the distribution group ownership, including how users can be added to the group. To view the new UI, open a distribution group's property dialog box (right-click the group, and then click Properties). The Group Information and the Membership Approval tabs include the new functionality. The following table lists the new parameters that support user-created distribution groups.

New parameters added to distribution group cmdlets

New parameter MemberDepartRestriction Used in cmdlets New-DistributionGroup Set-DistributionGroup New-DistributionGroup Set-DistributionGroup Remove-DistributionGroup Set-DistributionGroup Add-DistributionGroupMember Remove-DistributionGroupMember Set-DistributionGroup Set-DistributionGroup

MemberJoinRestriction

BypassSecurityGroupManagerCheck

MemberDepartRestriction MemberJoinRestriction

Also, the ManagedBy parameter has been updated to indicate ownership of a distribution group. Users specified in the ManagedBy parameter can modify the distribution group settings. Note: The ManagedBy parameter functionality for dynamic distribution groups didn't change. For more information about distribution groups, see Understanding Recipients and Managing Distribution Groups. Return to top

Permission Management for Mailbox Folders

You can manage folder-level permissions for all folders within a user's mailbox. Sharing mailbox folders and calendar folders is managed through a new set of cmdlets. These cmdlets allow you to view, remove, and add permissions for specific users on all designated mailbox folders:

Add-MailboxFolderPermission Get-MailboxFolderPermission Remove-MailboxFolderPermission Return to top

Bulk Recipient Management in the EMC

Exchange 2007 Service Pack 1 (SP1) introduced bulk recipient management for moving, removing, disabling, and enabling mailboxes in the EMC. In Exchange 2010, this functionality is expanded to include the following tasks:

Properties You can select multiple recipients in the result pane, and then click Properties in the action pane. Properties that you can't bulk edit are unavailable. Note: You can only bulk edit recipient properties when the same recipient types are selected. Send Mail You can select multiple recipients in the result pane, and then click Send Mail in the action pane to send an e-mail to multiple recipients. For more information, see the Send Mail section later in this topic. Return to top

Personal Archive
A personal archive is a specialized mailbox associated with a user's primary mailbox. It appears alongside the primary mailbox folders in Outlook 2010 or Outlook Web App. Users have direct access to e-mail within the archive just as they would their primary mailbox. Users can drag e-mail from .pst files into the personal archive for easier online access. Through the use of retention policies, e-mail items from the primary mailbox can be automatically offloaded to the personal archive. This reduces the mailbox size and improves application and network performance. In addition, users can use Outlook 2010 or Outlook Web App to search both their personal archive and primary mailbox. To learn more, see Understanding Personal Archives. Return to top

Send Mail
You can send mail to multiple recipients from the EMC. Select multiple recipients in the result pane, and then click Send Mail in the action pane. You must configure an e-mail account on the computer from which you are sending mail. You can send mail to the following recipient types:

User mailboxes Mail contacts Mail users Dynamic distribution groups Distribution groups You can't send mail to resource mailboxes. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

New Transport Functionality

Exchange 2010 Applies to: Exchange Server 2010 SP2 Topic Last Modified: 2009-11-11 The following is a list of new or improved transport and routing functionality that's included in Microsoft Exchange Server 2010:

MailTips MailTips provide extra information that's displayed to senders while they're composing e-mail messages. MailTips provide information about the messages such as details about the recipients and their availability, or reasons the message wouldn't be delivered. For example, if the person the message is addressed to is out of the office, senders will be informed about this while they're composing the message. To learn more about MailTips, see Understanding MailTips. Shadow redundancy Messages that are submitted to an Exchange 2010 Hub Transport server are stored in the transport database until the next hop reports successful delivery of the message. If the next hop doesn't report successful delivery and it fails, the message is resubmitted for delivery. To learn more about shadow redundancy, see Understanding Shadow Redundancy. Moderated transport Exchange 2010 provides an approval workflow for sending messages to recipients. When you configure a recipient for moderation, all messages sent to that recipient must go through an approval process. To learn more about moderated transport, see Understanding Moderated Transport. End-to-end message tracking Exchange 2010 transport provides users with the ability to track messages from submission to the final destination. There is a new message tracking tool that makes it easy for any user role, from end-user to administrator, to track messages. For more information, see Understanding Message Tracking. Support for disabling TLS for WAN topologies In certain topologies where WAN Optimization Controller (WOC) devices are used, the TLS encryption of SMTP traffic may be undesirable. Exchange 2010 supports disabling TLS for hub-to-hub communications for these specific scenarios. For more information, see Disabling TLS Between Active Directory Sites to Support WAN Optimization. Incremental EdgeSync In Exchange 2010, the EdgeSync process has been changed to keep track of synchronized information and only synchronize the changes since the last replication cycle. This significantly reduces network traffic and greatly improves synchronization efficiency. For more information, see Understanding Edge Subscriptions. Transport rule predicates and actions Transport rules inspect messages for conditions specified in the rules. Messages that meet the conditions, and none of the exceptions, get the specified actions applied to them. Exchange 2010 includes several new predicates and actions, providing additional flexibility in creating rules and additional options for actions that can be applied to messages. For more information, see Transport Rule Predicates and Transport Rule Actions. Transport rule cmdlet improvements The New-TransportRule and Set-TransportRule cmdlets have been enhanced, allowing you to specify all predicates and actions in a single command. All predicates and actions are now available for use as parameters with these cmdlets. For more information, see New-TransportRule and Set-TransportRule. Transport rules integration with AD RMS Exchange 2010 provides you the ability to create rules that require Active Directory Rights Management Services (AD RMS) protection based on keywords or patterns. For more information, see Understanding Transport Protection Rules. Distribution group expansion improvements The handling of distribution group expansion has improved in Exchange 2010. First, the amount of memory that's used for caching distribution group membership has been capped by a configurable limit. This change prevents the cache from consuming too much memory, and thereby impacting performance in large environments. Exchange 2010 also queries Active Directory in a more efficient manner when processing large distribution groups with delivery restrictions, improving the performance of message delivery to large distribution groups. Message throttling improvements In Exchange 2010, you can configure a Receive connector to monitor the rate of message submissions by users, IP addresses, or both. If you configure a Receive connector to monitor the message submission rate for users, it ensures that a specific user doesn't exceed the message rate that it's allowed, regardless of the IP address the connections are coming from. The default client Receive connector created on the Hub Transport servers is configured this way. Latency management With Exchange 2010 transport, you can measure service levels delivered relative to your service level agreement (SLA) goals. Exchange 2010 provides you the ability to measure latencies for each hop, as well as end-to-end latency. 2010 Microsoft Corporation. All rights reserved.
2013 Microsoft. All rights reserved.

Discontinued Features
Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2013-01-10 This topic discusses the components, features, and functionalities that have been removed, discontinued, or replaced in Microsoft Exchange Server 2010. For information about API and development tool changes, see Migrating from Earlier Technologies to Exchange 2010. Contents Discontinued Features from Exchange 2010 RTM to Exchange 2010 SP1 Discontinued Features from Exchange 2007 to Exchange 2010 Discontinued Features from Exchange 2003 to Exchange 2010

Discontinued Features from Exchange 2010 RTM to Exchange 2010 SP1

This section lists the Microsoft Exchange Server 2010 RTM features that are discontinued in Microsoft Exchange Server 2010 SP1.

Feature Export-Mailbox and ImportMailbox cmdlets EnableAntispamUpdates Federated Delivery ISInteg Managed folders in the Exchange Management Console (EMC)

Comments and mitigation Use export requests or import requests. For more information, see Understanding Mailbox Import and Export Requests.

Use Forefront Security for Exchange Server to obtain automatic anti-spam updates. For more information, see Forefront Online Protection for Exchange. Use Tenant Mail Flow control. For more information, see Understanding Transport Options.

Use New-MailboxRepairRequest or New-PublicFolderDatabaseRepairRequest. In Exchange 2010 SP1, use the Exchange Management Shell to administer managed folder features such as managed default folders, managed custom folders, and managed folder mailbox policies. You can use the EMC and the Shell to manage retention policies and retention tags, the new messaging records management (MRM) feature introduced in Exchange 2010. For more information, see Deploying Messaging Records Management.

Discontinued Features from Exchange 2007 to Exchange 2010 RTM

This section lists the Microsoft Exchange Server 2007 features that are discontinued in Exchange 2010.

APIs and Development Features

Feature Exchange WebDAV

Comments and mitigation Use Introduction to Web Services or Differences between the EWS Managed API and EWS. Alternatively, you can maintain an Exchange 2007 server for mailboxes that are managed by applications that use WebDAV. For more information, see Migrating from WebDAV to Exchange 2010.

Architecture Features

Feature DSProxy

Comments and mitigation Exchange 2010 uses the RPC Client Access service and the Address Book service to perform this functionality. For more information, see Understanding RPC Client Access and Understanding the Address Book Service. Exchange 2010 uses database copy functionality. For information, see Understanding Mailbox Database Copies. Exchange 2010 uses Volume Shadow Copy Service (VSS)-based copies, such as Windows Server Backup and the VSS-plug-in included with Exchange 2010. For information, see Understanding Backup, Restore and Disaster Recovery.

Storage groups Extensible Storage Engine (ESE) streaming backup APIs

User Datagram Protocol (UDP) notifications

Support for User Datagram Protocol (UDP) notifications is removed from Exchange 2010. This impacts the experience when Outlook 2003 clients connect to their mailboxes on an Exchange 2010 server. For more information, see Microsoft Knowledge Base article 2009942, Folders take a long time to update when an Exchange Server 2010 user uses Outlook 2003 in online mode. Note: Support for User Datagram Protocol (UDP) notifications is added in Microsoft Exchange Server 2010 Service Pack 1 (SP1) Rollup 3 (RU3). To obtain Exchange 2010 SP1 Update RU3, see Microsoft Knowledge Base article 2009942, Folders take a long time to update when an Exchange Server 2010 user uses Outlook 2003 in online mode.

High Availability Features

Feature Cluster continuous replication (CCR) Local continuous replication (LCR) Standby continuous replication (SCR) Single copy cluster (SCC) Setup /recoverCMS Clustered mailbox servers

Comments and mitigation Exchange 2010 uses database availability groups (DAGs) and mailbox database copies. For information, see High Availability and Site Resilience. Exchange 2010 uses DAGs and mailbox database copies. For information, see High Availability and Site Resilience.

Exchange 2010 uses DAGs and mailbox database copies. For information, see High Availability and Site Resilience.

Exchange 2010 uses DAGs and mailbox database copies. For information, see High Availability and Site Resilience. Exchange 2010 uses Setup /m:recoverServer. For information, see Recover a Database Availability Group Member Server. Exchange 2010 uses DAGs and mailbox database copies. For information, see High Availability and Site Resilience.

Client Access Features

Feature Client authentication using Integrated Windows authentication (NTLM) for POP3 and IMAP4 users

Comments and mitigation NTLM isn't supported for POP3 or IMAP4 client connectivity in the RTM version of Exchange 2010. Connections from POP3 or IMAP4 client programs using NTLM will fail. If youre running the RTM version of Exchange 2010, the recommended POP3 and IMAP4 setting alternatives to NTLM are: Kerberos (GSSAPI) Plain Text Authentication with SSL If youre using the RTM version of Exchange 2010, to use NTLM, you must retain an Exchange 2003 or Exchange 2007 server in your Exchange 2010 organization. Support for NTLM authentication for POP3 and IMAP4 connectivity has been brought back in Exchange 2010 SP1. For more information, see Set-PopSettings and Set-ImapSettings.

Outlook Web App Features

Feature Document access

Comments and mitigation Can't use Microsoft Office Outlook Web App to access Microsoft Office SharePoint document libraries and Microsoft Windows file shares. Web Parts aren't supported in Exchange 2010 RTM. This feature has been brought back in Exchange 2010 SP1. Users can't change the theme in Outlook Web App RTM. This feature has been brought back in Exchange 2010 SP1. There is no option to display the reading pane at the bottom of the Outlook Web App window. This feature has been brought back in Exchange 2010 SP1.

Web Parts User-selectable themes Reading pane at the bottom of the page

Recipient Related Features

Feature Move-Mailbox cmdlet set

Comments and mitigation Use move requests to move mailboxes. For information, see Understanding Move Requests.

Return to top

Discontinued Features from Exchange 2003 to Exchange 2010

This section lists the Exchange Server 2003 features that are discontinued in Exchange 2010.

APIs and Development Features

Feature Proxy address generators ExCDO 1.2.1 MAPI32 CDOEX (CDO 3.0) Exchange WebDAV extensions ExOLEDB Store events Return to top

Comments and mitigation Use the Shell. Use Introduction to Web Services. Use Introduction to Web Services. Use Introduction to Web Services. Use Introduction to Web Services. Use Introduction to Web Services. Use Introduction to Web Services.

Architecture Features

Feature Routing groups Administrative groups Intelligent Message Filter Link state routing Routing objects Networkattached storage Exchange Installable File System (ExIFS) Event service Recovery storage group User Datagram Protocol (UDP)

Comments and mitigation Exchange 2010 uses Active Directory site-based routing. For information, see Understanding Message Routing.

Exchange 2010 uses the Exchange 2007 split permissions model that's based on universal security groups. For information, see Understanding Split Permissions. Exchange 2010 uses anti-spam agents in the Hub Transport and Edge Transport server roles. For information, see Understanding Anti-Spam and Antivirus Functionality.

Exchange 2010 uses Active Directory site-based routing. For information, see Understanding Message Routing.

If you need this functionality, retain an Exchange 2003 server in your Exchange 2010 organization.

Exchange 2010 supports Internet SCSI (iSCSI).

Use Introduction to Web Services or MAPI.

If you need this functionality, retain an Exchange 2003 server in your Exchange 2010 organization. Exchange 2010 uses the recovery database. For information, see Recovery Databases.

Support for User Datagram Protocol (UDP) notifications is removed from Exchange 2010. This impacts the experience when Outlook 2003 clients connect to their mailboxes on an Exchange 2010 server. For more information, see Microsoft Knowledge Base article 2009942, Folders take a long time to update when an Exchange Server 2010 user uses Outlook 2003 in online mode.

Connector Features

Feature Microsoft Exchange Connector for Novell GroupWise and migration tools Microsoft Exchange Connector for Lotus Notes

Comments and mitigation If you need this functionality, retain an Exchange 2003 server in your Exchange 2010 organization.

Use the appropriate tools for coexisting and migrating from Lotus Notes. These tools are available at the Interoperability Bridges and Lab Center Web site.

Protocol Features

Feature Network News Transfer Protocol (NNTP) POP3 or IMAP4 graphical user interface (GUI) management X.400 message transfer agent (MTA) SMTP virtual server instances

Comments and mitigation If you need this functionality, retain an Exchange 2003 server in your Exchange 2010 organization. Use the Exchange Management Console (EMC) or the Exchange Management Shell. For information, see Managing POP3 and IMAP4. If you need this functionality, retain an Exchange 2003 server in your Exchange 2010 organization. Use Exchange 2010 SMTP connectors. For information, see Understanding Send Connectors and Understanding Receive Connectors.

Public Folder Features

Feature Non-MAPI top-level hierarchies in a public folder store Public folder access by using NNTP Public folder access by using IMAP4

Comments and mitigation If you need this functionality, retain an Exchange 2003 server in your Exchange 2010 organization. If you need this functionality, retain an Exchange 2003 server in your Exchange 2010 organization. If you need this functionality, retain an Exchange 2003 server in your Exchange 2010 organization.

Client Access Features

Feature Client authentication using Integrated Windows authentication (NTLM) for POP3 and IMAP4 users

Comments and mitigation NTLM isn't supported for POP3 or IMAP4 client connectivity. The recommended POP3 and IMAP4 setting alternatives to NTLM are: Kerberos (GSSAPI) Plain Text Authentication with SSL Connections from POP3 or IMAP4 client programs to Exchange 2010 will fail. If you need this functionality, retain an Exchange 2003 or Exchange 2007 server in your Exchange 2010 organization.

Outlook Web App Features

Feature Calendar search Views in the Contacts folder Printing

Comments and mitigation The search feature isnt available for the Calendar folder in Outlook Web App. The Address Cards and Detailed Address Cards views are no longer available in Outlook Web App. The option is to use the Reading Pane when viewing Contacts. Contacts cant be sorted by location. Contacts and Tasks dont include a print option in Exchange 2010 Outlook Web App.

Recipient-Related Features

Feature Exchange extensions in Active Directory Users and Computers Exchange Server Mailbox Merge wizard (ExMerge.exe)

Comments and mitigation Exchange 2010 includes recipient management in the EMC. For information, see Managing Mailbox Servers.

In Exchange Server 2010 RTM, use the Export-Mailbox cmdlet or the Move Request cmdlet set. In Exchange Server 2010 SP1, use the Mailbox Repair Request cmdlet set or the Move Request cmdlet set. For information, see Recipient Cmdlets. Use retention policies, the MRM feature introduced in Exchange 2010, or managed folder mailbox policies, the MRM feature introduced in Exchange 2007 (also available in Exchange 2010). For more information, see Understanding Messaging Records Management. Use the Update-AddressList and Update-EmailAddressPolicy cmdlets. To replace the full functionality of the Recipient Update Service, you can use the Task Scheduler to schedule these Shell commands. For information, see Task Scheduler.

Mailbox Manager Policies

Recipient Update Service

Tools and Management Features

Feature Monitoring and status node Message Tracking Center node and tracking mechanism Mailbox Recovery Center Mailbox Management Service

Comments and mitigation Use a monitoring solution such as System Center 2012 Cloud & Datacenter Management. Use the Tracking Log Explorer and Message Tracking tools. For information, see Understanding Message Tracking.

Use the Restore-Mailbox cmdlet. Use messaging records management (MRM) or retention policies. For information, see Understanding Messaging Records Management and Understanding Retention Tags and Retention Policies. In Exchange Server 2010 RTM, use the Export-Mailbox cmdlet or the Move Request cmdlet set. In Exchange 2010 SP1, use the Mailbox Repair Request cmdlet set or the Move Request cmdlet set. For information, see Recipient Cmdlets. Use the New-MoveRequest cmdlet or the Local Move Request and Remote Move Request wizards to move mailboxes from Exchange 2003 to Exchange 2010. For information, see Understanding Move Requests. Use the Autodiscover service. For information, see Understanding the Autodiscover Service.

Clean Mailbox tool

Migration wizard

Exchange Profile Redirector tool (ExProfRe) Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Overview of Exchange 2010 Server Roles

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-01-20 Because organizations tend to group their management tasks around a core set of server roles, Exchange 2010 maps Exchange Server management to this same approach. A server role is a unit that logically groups the required features and components needed to perform a specific function in the messaging environment. The requirement of a server role is that it is a server that could be run as an atomic unit of scalability. A server role is composed of a group of features. Server roles, the primary unit of deployment, enable administrators to easily choose which features are installed on an Exchange server. Logically grouping features in server roles offers the following advantages:

Reduces attack surface on an Exchange server. Allows you to install and configure an Exchange server the way you intend to use it. Offers the ability to fully customize a server to support your business goals and needs. The following figure illustrates a domain with each server role deployed.

Exchange 2010 includes the following server roles:

Mailbox Server This server hosts mailboxes and public folders. For more information about the Exchange 2010 Mailbox server role, see Overview of the Mailbox Server Role. Client Access Server This is the server that hosts the client protocols, such as Post Office Protocol 3 (POP3), Internet Message Access Protocol 4 (IMAP4), Secure Hypertext Transfer Protocol (HTTPS), Outlook Anywhere, Availability service, and Autodiscover service. The Client Access Server also hosts Web services. For more information about the Exchange 2010 Client Access server role, see Client Access. Unified Messaging Server This is the server that connects a Private Branch eXchange (PBX) system to Exchange 2010. For more information about the Exchange 2010 Unified Messaging server role, see Unified Messaging. Hub Transport Server This is the mail routing server that routes mail within the Exchange organization. For more information about the Exchange 2010 Hub Transport server role, see Transport and Overview of the Hub Transport Server Role. Edge Transport Server This is the mail routing server that typically sits at the perimeter of the topology and routes mail in to and out of the Exchange organization. For more information about the Exchange 2010 Edge Transport server role, see Transport and Overview of the Edge Transport Server Role. 2010 Microsoft Corporation. All rights reserved.
2013 Microsoft. All rights reserved.

Roadmap for Exchange Features

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 This roadmap helps you get acquainted with all the features in Microsoft Exchange Server 2010. The first section lists all the features that can be managed by using either the Exchange Management Console (EMC) or the Exchange Management Shell. This section also shows you how to navigate to the feature in the EMC and provides a link to the corresponding management topic. However, not all features and tasks can be managed in the EMC. Therefore, the second section lists the features that can be managed only in the Shell and provides links to the corresponding cmdlet reference topic. Important: If you're looking for a feature that was in Exchange Server 2007 or Exchange Server 2003 and you can't find it in this topic, the feature may have been renamed or removed in Exchange 2010. For more information, see Discontinued Features.

Features Managed in the EMC and the Shell

The following table is organized alphabetically by feature. It includes the click path that shows you how to get to the feature and the related topics that explain how to manage the feature. Note: This table shows how to locate features in the EMC. However, because all features can be managed by using the Shell, the management topics include both the EMC and Shell procedures. The click paths follow the EMC layout from left to right, starting in the console tree and working toward the action pane. For example, consider the following click path for managing Exchange certificates: Server Configuration > (Select Server) > Exchange Certificates > (Select Certificate). The following illustration maps this click path from the console tree, to the result pane, to the work pane, and then finally to the action pane that lists options for managing the specified certificate.

Exchange 2010 features managed in the EMC and Shell

Feature Accepted domains How to get there in the EMC Organization Configuration > Hub Transport > Accepted Domains tab Edge Transport > Accepted Domains tab Organization Configuration > Mailbox > Address Book Policies tab Related management topics Managing Accepted and Remote Domains Managing Address Book Policies

Address book policies

Address book policies, apply to user Address lists Archive quotas, apply to mailbox

Recipient Configuration > Mailbox > (Select Mailbox) > Properties > Mailbox Settings tab > Address Book Policy > Properties Organization Configuration > Mailbox > Address Lists tab Recipient Configuration > Mailbox > (Select Mailbox) > Properties > Mailbox Settings tab > Archive Quota > Properties Toolbox > Best Practices Analyzer > Open Tool Recipient Configuration > Mailbox > (Select Mailbox) Properties > Calendar Settings tab Server Configuration > Client Access > (Select Server) > Properties Edge Transport > (Select Server) > Anti-spam tab > Content Filtering Microsoft Exchange On-Premises > Customer Feedback tab

Assign an Address Book Policy to a Mail User Managing Address Lists Configure Archive Quotas for a Personal (On-Premises) Archive Microsoft Exchange Analyzers Managing User Mailboxes

Best Practices Analyzer Calendar settings, apply to mailbox Client Access server settings Content filtering Customer Experience Improvement Program, opt-in or opt-out organization Customer Experience Improvement Program, opt-in or opt-out servers

Managing Client Access Servers Configure Content Filtering Properties Opt-in or Opt-out of the Customer Experience Improvement Program

Server Configuration > (Select Server) > Properties > Customer Feedback Options tab Server Configuration > (Select Server Role Node) > (Select Server) > Properties > Customer Feedback Options tab Organization Configuration > Mailbox > Database Availability Groups tab > (Select Database Availability Group) > Networks tab

Opt-in or Opt-out of the Customer Experience Improvement Program

Database availability group networks

Create a Database Availability Group Network Configure Database Availability Group Network Properties Managing Database Availability Groups Managing Mailbox Database Copies

Database availability groups

Organization Configuration > Mailbox > Database Availability Groups tab

Database copies

Organization Configuration > Mailbox > Database Management tab > (Select Mailbox Database) > Database Copies tab Organization Configuration > Mailbox > Database Management tab Organization Configuration > Mailbox > Database Management tab > (Select Mailbox Database) > Database Copies tab Organization Configuration > Mailbox > Database Management tab

Database switchover

Switchovers and Failovers

Databases

Managing Mailbox Databases Managing Public Folder Databases Managing Details Templates Manage Diagnostic Logging Levels

Details Templates Editor Diagnostic logging

Toolbox > Details Templates Editor > Open Tool Server Configuration > Mailbox > (Select Server) > Manage Diagnostic Logging Properties Recipient Configuration > Distribution Group Recipient Configuration > Distribution Group Organization Configuration > Hub Transport > Edge Subscriptions tab Edge Transport > (Select Server) > Properties Organization Configuration > Hub Transport > E-mail Address Policies tab Toolbox > Public Folder Management Console > Default Public Folders > (Select Mail-Enabled Public Folder) > Properties > E-Mail Addresses tab Recipient Configuration > (Select Recipient) > Properties > E-Mail Addresses tab

Distribution groups Dynamic distribution groups Edge Subscriptions Edge Transport server settings E-mail address policies E-mail addresses, apply to public folder E-mail addresses, apply to recipient

Managing Distribution Groups Managing Distribution Groups Managing Edge Subscriptions Managing Transport Servers Managing E-Mail Address Policies Configure Public Folder Properties

Configure User and Resource Mailbox Properties Configure Mail User Properties Configure Mail Contact Properties Configure Distribution Group Properties Configure Dynamic Distribution Group Properties Managing Exchange ActiveSync with Policies Add Users to an Exchange ActiveSync Mailbox Policy Configure ECP Virtual Directory Properties

Exchange ActiveSync mailbox policies Exchange ActiveSync mailbox policies, apply to mailbox Exchange Control Panel Web site

Organization Configuration > Client Access > Exchange ActiveSync Mailbox Policies tab Recipient Configuration > Mailbox > (Select Mailbox) > Properties > Mailbox Features tab > Exchange ActiveSync > Properties Server Configuration > Client Access > Exchange Control Panel tab > (Select Web Site) > Properties

External Client Access domains

Server Configuration > Client Access > Configure External Client Access Domain

Configure External Client Access Namespaces Managing Federation Manage Full Access Permissions

Federation trusts Full Access permission, mailbox

Organization Configuration > Federation Trust tab Recipient Configuration > Mailbox > (Select Mailbox) > Manage Full Access Permission Server Configuration > Hub Transport > (Select Server) > Properties Server Configuration > Client Access > POP3 and IMAP4 tab > IMAP4 > Properties Recipient Configuration > Mailbox > (Select Mailbox) > Properties > Mailbox Features tab > IMAP4 Edge Transport > (Select Server) > Anti-spam tab > IP Allow List Providers

Hub Transport server settings IMAP4, configure

Managing Transport Servers View or Configure IMAP4 Properties

IMAP4, enable, disable, or specify the MIME format for a mailbox IP Allow List providers

Enable or Disable IMAP4 Access for a User Configure IP Allow List Providers Properties Configure IP Allow List Properties Configure IP Block List Properties Configure IP Block List Providers Properties Managing Journaling Enter Product Key Collect Organizational Health Data

IP Allow lists IP Block lists IP Block List providers

Edge Transport > (Select Server) > Anti-spam tab > IP Allow List Edge Transport > (Select Server) > Anti-spam tab > IP Block List Edge Transport > (Select Server) > Anti-spam tab > IP Block List Providers

Journal rules License, input key License, view server and client licensing information Mail contacts

Organization Configuration > Hub Transport > Journal Rules tab Server Configuration > Enter Product Key Group Microsoft Exchange On-Premises > Collect Organizational Health Data tab

Recipient Configuration > Mail Contact

Managing Mail Contacts and Mail Users NA Managing Mail Contacts and Mail Users Managing Mailbox Servers Managing User Mailboxes Connect to the Disconnected Mailbox Server Connect a Disconnected Personal (OnPremises) or Cloud-Based Archive Managing Move Requests

Mail Flow Troubleshooter Mail users

Toolbox > Mail Flow Troubleshooter > Open Tool Recipient Configuration > Mail Contact

Mailbox server settings Mailboxes, configure Mailboxes, disconnected

Server Configuration > Mailbox > (Select Server) > Properties Recipient Configuration > Mailbox Recipient Configuration > Disconnected Mailbox

Mailboxes, move

Recipient Configuration > Mailbox > (Select Mailbox) > New Local Move Request or New Remote Move Request Recipient Configuration > Mail Contact Recipient Configuration > Mailbox > (Select Mailbox) > Properties > Mailbox Features tab > MAPI Organization Configuration > Hub Transport > Global Settings tab > (Select Transport Settings) > Properties > Message Delivery tab Recipient Configuration > (Select Recipient) > Properties > Mail Flow Settings tab > Message Delivery Restrictions > Properties Recipient Configuration > (Select Recipient) > Properties > Mail Flow Settings tab > Message Size Restrictions > Properties

Mailboxes, remote MAPI, enable or disable for mailbox Message delivery

Managing User Mailboxes Enable or Disable MAPI for a User Mailbox Configure Transport Settings Properties Configure Message Delivery Restrictions Configure Message Size Limits for a Mailbox or a Mail-Enabled Public Folder Track Messages with Delivery Reports

Message delivery restrictions, apply to recipient Message size restrictions, apply to recipient

Message tracking

Toolbox > Message Tracking > Open Tool > (Log On to Outlook Web App) > (Select to Manage My Organization) > Reporting > Delivery Reports tab Organization Configuration > Mailbox > Retention Policies and Retention Policy Tags tabs Recipient Configuration > Move Request Server Configuration > Client Access > Offline Address Book Distribution tab

Messaging records management (MRM) 2.0: Retention policies Move request, view or remove Offline address book virtual directory, configure

Deploying Messaging Records Management Managing Move Requests Configure Offline Address Book Distribution Properties

Offline address books (OABs) Organization relationships Organizational health, update

Organization Configuration > Mailbox > Offline Address Book tab Organization Configuration > Organization Relationships tab Microsoft Exchange On-Premises > Organizational Health tab> Collect Organizational Health Data Microsoft Exchange On-Premises > Organizational Health Data tab Server Configuration > Client Access > (Select Server) > Properties > Outlook Anywhere tab Server Configuration > Client Access > (Select Server) > Enable Outlook Anywhere

Managing Offline Address Books Managing Federated Delegation Collect Organizational Health Data

Organizational health, view Outlook Anywhere, configure

Collect Organizational Health Data Managing Outlook Anywhere

Outlook Anywhere, enable or disable Outlook Web App mailbox policies Outlook Web App mailbox policies, apply to mailbox Outlook Web App virtual directories, configure Performance Monitor

Enable Outlook Anywhere Disable Outlook Anywhere Managing Outlook Web App Mailbox Policies Apply an Outlook Web App Mailbox Policy to a Mailbox Managing Outlook Web App Virtual Directories Performance and Reliability Monitoring Step-by-Step Guide for Windows Server 2008 NA Connect a Disconnected Personal (OnPremises) or Cloud-Based Archive Create a Personal (On-Premises) or Cloud-Based Archive for a New Mailbox Enable a Personal (On-Premises) or Cloud-Based Archive for an Existing Mailbox Create a Local Move Request Create a Remote Move Request That has Exchange 2010 in Both Forests Managing POP3 and IMAP4

Organization Configuration > Client Access > Outlook Web App Mailbox Policies tab Recipient Configuration > Mailbox > (Select Mailbox) > Properties > Mailbox Features tab > Outlook Web App > Properties Server Configuration > Client Access > Outlook Web App tab

Toolbox > Performance Monitor > Open Tool

Performance Troubleshooter Personal archive, disconnected

Toolbox > Performance Troubleshooter > Open Tool Recipient Configuration > Disconnected Mailbox

Personal archive, create

Recipient Configuration > New Mailbox

Personal archive, enable or disable archive on existing mailbox Personal archive, move

Recipient Configuration > Mailbox > (Select Mailbox) > Enable Archive or Disable Archive

Recipient Configuration > Mailbox > (Select Archive Mailbox) > New Local Move Request or New Remote Move Request > Move only the archive mailbox

POP3, configure

Server Configuration > Client Access > (Select Server) > POP3 and IMAP4 tab > POP3 > Properties Recipient Configuration > Mailbox > (Select Mailbox) > Properties > Mailbox Features tab > POP3 Organization Configuration > Mailbox > Database Management tab Toolbox > Public Folder Management Console > Default Public Folders > (Select Public Folder) > Manage Settings

POP3, enable or disable for mailbox Public folder databases Public folder client permissions

Enable or Disable POP3 Access for a User Managing Public Folder Databases Use the Public Folder Management Console to Manage Public Folder Settings Configure Public Folder Replication

Public folder replication settings

Toolbox > Public Folder Management Console > Default Public Folders > (Select Public Folder) > Properties > Replication tab Toolbox > Public Folder Management Console > Default Public Folders > (Select Public Folder) > Update Content Toolbox > Public Folder Management Console > Default Public Folders Toolbox > Queue Viewer > Open Tool Server Configuration > Hub Transport > Receive Connectors Edge Transport > Receive Connectors Edge Transport > (Select Server) > Anti-spam tab > Recipient Filtering

Public folder replication update

Configure Public Folder Replication

Public folders Queue Viewer Receive connectors

Managing Public Folders Using Queue Viewer Managing Connectors

Recipient filtering

Managing Anti-Spam and Antivirus Features Exchange Remote Connectivity Analyzer Tool Managing Accepted and Remote Domains

Remote Connectivity Analyzer

Toolbox > Remote Connectivity Analyzer > Open Tool

Remote domains

Organization Configuration > Hub Transport > Remote Domains tab

Reset Exchange Client Access server virtual directories Resource mailbox, configure

Server Configuration > Client Access > (Select Server) > Reset Virtual Directory

Reset Client Access Virtual Directories

Recipient Configuration > (Select Resource Mailbox) > Properties

Managing Resource Mailboxes and Scheduling Administrator Roles Tab User Roles Tab Using the Routing Log Viewer Manage Send As Permissions for a Mailbox Manage Send As Permissions for MailEnabled Public Folders Managing Connectors

Role Based Access Control (RBAC) User Editor Routing Log Viewer Send As permissions, mailbox

Toolbox > Role Based Access Control (RBAC) User Editor > Open Tool > (Log On to Outlook Web App) > Administrator Roles tab and User Roles tab Toolbox > Routing Log Viewer > Open Tool Recipient Configuration > Mailbox > (Select Mailbox) > Manage Send As Permission Toolbox > Public Folder Management Console > Default Public Folders > (Select Mail-Enabled Public Folder) > Manage Send As Permission Organization Configuration > Hub Transport > Send Connectors tab Edge Transport > Send Connectors tab Recipient Configuration > Mailbox > (Select Mailbox) > Properties > Mail Flow Settings tab > Delivery Options > Properties Toolbox > Public Folder Management Console > Default Public Folders > (Select Mail-Enabled Public Folder) > Properties > Mail Flow Settings tab > Delivery Options > Properties Edge Transport > (Select Server) > Anti-spam tab> Sender Filtering

Send As permissions, mailenabled public folder Send connectors

Send on behalf, mailbox

Configure User and Resource Mailbox Properties Configure Public Folder Properties

Send on behalf, mail-enabled public folder

Sender filtering

Managing Anti-Spam and Antivirus Features Managing Anti-Spam and Antivirus Features Managing Anti-Spam and Antivirus Features Perform a Server Switchover Managing Federated Delegation Managing Federated Delegation

Sender ID

Edge Transport > (Select Server) > Anti-spam tab > Sender ID

Sender reputation

Edge Transport > (Select Server) > Anti-spam tab> Sender Reputation

Server switchover Sharing policies Sharing policies, apply to mailbox

Server Configuration > Mailbox > (Select Server) > Switchover Server Organization Configuration > Mailbox > Sharing Policies tab Recipient Configuration > Mailbox > (Select Mailbox) > Properties > Mailbox Settings tab > Sharing > Properties Recipient Configuration > Mailbox > (Select Mailbox) > Properties > Mailbox Settings tab > Storage Quotas > Properties Toolbox > Tracking Log Explorer > Open Tool Organization Configuration > Hub Transport > Global Settings tab > Transport Settings > Properties > General tab Organization Configuration > Hub Transport > Global Settings tab > (Select Transport Settings) > Properties > General tab Organization Configuration > Hub Transport > Transport Rules tab Edge Transport > Transport Rules tab Organization Configuration > Hub Transport > Global Settings tab

Storage quotas, configure for a mailbox Tracking Log Explorer Transport dumpster

Configure Storage Quotas for a Mailbox NA Configure Transport Settings Properties Configure Transport Settings Properties Managing Transport Rules

Transport limits

Transport rules

Transport settings

Configure Transport Settings Properties Managing UM Auto Attendants Managing UM Dial Plans Managing UM Hunt Groups

UM auto attendants UM dial plans UM hunt groups

Organization Configuration > Unified Messaging > UM Auto Attendants tab Organization Configuration > Unified Messaging > UM Dial Plans tab Organization Configuration > Unified Messaging > UM IP Gateways tab > (Select IP Gateway) > UM Hunt Groups tab Organization Configuration > Unified Messaging > UM IP Gateways tab Organization Configuration > Unified Messaging > UM Mailbox Policies tab Recipient Configuration > Mailbox > (Select Mailbox) > Properties > Mailbox Features tab > Unified Messaging > Properties Server Configuration > Unified Messaging > Properties Server Configuration > Unified Messaging > (Select UM Server) > Disable Immediately or Disable After Calls

UM IP gateways UM mailbox policies UM-enabled users

Managing UM IP Gateways Managing UM Mailbox Policies Managing Unified Messaging Users

Unified Messaging server settings Unified Messaging server, enable or disable

Managing Unified Messaging Servers Enable Unified Messaging on Exchange 2010

Disable Unified Messaging on Exchange 2010

Features Managed Only in the Shell

The following table lists features managed only by using the Shell and includes links to the corresponding cmdlet reference topics. Exchange 2010 features managed only in the Shell

Feature Address rewriting

Manage by using AddressRewriteEntry cmdlet set See Transport Cmdlets Get-AdminAuditLogConfig Set-AdminAuditLogConfig New-AdminAuditLogSearch Search-AdminAuditLog Write-AdminAuditLog AttachmentFilterEntry cmdlet set AttachmentFilterListConfig cmdlet set See Anti-Spam Cmdlets ClientAccessArray cmdlet set See Client Access Cmdlets CmdletExtensionAgent cmdlet set See Cmdlet Extension Agent Cmdlets Set-DatabaseAvailabilityGroup Set-DatabaseAvailabilityGroup Set-DatabaseAvailabilityGroup DeliveryAgentConnector cmdlet set See Transport Cmdlets EdgeSyncServiceConfig cmdlet set See Transport Cmdlets Start-EdgeSynchronization Test-EdgeSynchronization Test-ActiveSyncConnectivity Export-ActiveSyncLog Test-EcpConnectivity Set-MailboxDatabase, with the -IndexEnabled parameter Test-ExchangeSearch Get-FailedContentIndexDocuments GlobalAddressList cmdlet set See Mailbox Cmdlets Test-ImapConnectivity MailboxImportRequest cmdlet set MailboxExportRequest cmdlet set See Understanding Importing and Exporting Files in the Exchange Management Shell IRMConfiguration cmdlet set See Messaging Policy and Compliance Cmdlets Test-IPAllowListProvider Test-IPBlockListProvider ADSiteLink cmdlet set See Transport Cmdlets See Managing Mailbox Audit Logging Test-Mailflow

Administrator audit logging

Attachment filter agent

Client access array

Cmdlet extension agents

Database availability group network encryption and compression Database availability groups: Datacenter Activation Coordination mode Database availability groups: replication port Delivery agent connectors

Edge synchronization (EdgeSync) service settings, configure

EdgeSync, forcing or testing

Exchange ActiveSync connectivity, test Exchange ActiveSync log, export Exchange Control Panel connectivity, test Exchange Search

Global address lists (GALs)

IMAP4 connectivity, test Import\export mailbox data

Information Rights Management (IRM), configure

IP Allow and Block List providers, test

IP site link costs, Exchange-specific

Mailbox audit logging, configure and search Message flow, test

Messaging records management (MRM) 1.0: Managed folders

ManagedFolder cmdlet set ManagedFolderMailboxPolicy cmdlet set Start-ManagedFolderAssistant See Messaging Policy and Compliance Cmdlets MailboxSearch cmdlet set See Messaging Policy and Compliance Cmdlets New-OABVirtualDirectory Test-OutlookConnectivity OutlookProtectionRule cmdlet set See Messaging Policy and Compliance Cmdlets Test-OwaConnectivity New-OwaVirtualDirectory Remove-OwaVirtualDirectory Test-OutlookWebServices Test-PopConnectivity Test-PowerShellConnectivity PowerShellVirtualDirectory cmdlet set See Client Access Cmdlets RoleAssignmentPolicy cmdlet set See Permissions Cmdlets RoleGroup cmdlet set RoleGroupMember cmdlet set See Permissions Cmdlets ManagementRole cmdlet set See Permissions Cmdlets ManagementRoleEntry cmdlet set See Permissions Cmdlets ManagementRoleAssignment cmdlet set See Permissions Cmdlets ManagementScope cmdlet set See Permissions Cmdlets New-MailboxDatabase Restore-Mailbox Set-Mailbox, using the following parameters: RecoverableItemsQuota RecoverableItemsWarningQuota SingleItemRecoveryEnabled

Multi-Mailbox Search

Offline address book virtual directory, create Outlook client connectivity, test end-to-end Outlook Protection Rules

Outlook Web App connectivity, test Outlook Web App virtual directories, create or remove

Outlook Web services connectivity, test POP3 connectivity, test PowerShell, test connectivity PowerShell, virtual directories

RBAC management role assignment Policies

RBAC management role groups

RBAC management roles

RBAC management role entries

RBAC management role assignments

RBAC management scopes

Recovery database, create Recovery database, extract data Recovery items

Routing group connectors

RoutingGroupConnector cmdlet set See Transport Cmdlets Update-SafeList cmdlet set See Transport Cmdlets Search-Mailbox Test-SenderId ServiceEmailChannel cmdlet set See Client Access Cmdlets TransportAgent cmdlet set See Transport Cmdlets MessageLatencyReport cmdlet set See Transport Cmdlets

Safelist aggregation, force

Search mailbox and delete items Sender ID, test Service e-mail channel

Transport agents

Transport latency, calculating

Transport pipeline analysis UM connectivity, test UM incoming calls, view active Web services connectivity, test X.400 authoritative domains

Get-TransportPipeline Test-UMConnectivity Get-UMActiveCalls Test-WebServicesConnectivity X400AuthoritativeDomains cmdlet set See Transport Cmdlets

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Exchange 2010: Editions and Versions

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-11-04 Microsoft Exchange Server 2010 is available in two server editions: Standard Edition and Enterprise Edition. Enterprise Edition can scale to 100 databases per server; Standard Edition is limited to 5 databases per server. These licensing editions are defined by a product key. When you enter a valid license product key, the supported edition for the server is established. Product keys can be used for the same edition key swaps and upgrades only; they can't be used for downgrades. You can use a valid product key to move from the evaluation version (Trial Edition) of Exchange Server 2010 to either Standard Edition or Enterprise Edition. You can also use a valid product key to move from Standard Edition to Enterprise Edition. You can also license the server again using the same edition product key. For example, if you had two Standard Edition servers with two keys, but you accidentally used the same key on both servers, you can change the key for one of them to the other key that you were issued. You can take these actions without having to reinstall or reconfigure anything. After you enter the product key and restart the Microsoft Exchange Information Store service, the edition corresponding to that product key will be reflected. No loss of functionality will occur when the Trial Edition expires, so you can maintain lab, demo, training, and other non-production environments beyond 120 days without having to reinstall the Trial Edition of Exchange 2010. As mentioned earlier, you can't use product keys to downgrade from Enterprise Edition to Standard Edition, nor can you use them to revert to the Trial Edition. These types of downgrades can only be done by uninstalling Exchange 2010, reinstalling Exchange 2010, and entering the correct product key. For more information, see Enter Product Key.

Exchange 2010 Versions

Service Pack 2 (SP2) for Exchange Server 2010 is available and is the most recent version of the product. Service Pack 1 (SP1) for Exchange Server 2010 and the release to manufacturing (RTM) version of Exchange Server 2010 are also available.

Exchange 2010 Build Versioning

The SP1 version of Exchange 2010 is 14.01.0218.015. The RTM version of Exchange 2010 is 14.00.0639.021. This version information is consistently displayed in the Exchange Management Console, the Exchange Management Shell, and in the About Exchange Server 2010 Help dialog box. You can also use the Get-ExchangeServer cmdlet and examine the AdminDisplayVersion property for the Exchange 2010 build version. For more information about deploying fixes and update rollups for Exchange 2010, see Exchange 2010 Servicing.

Exchange 2010 License Types

Exchange 2010 on-premises is licensed in the Server/Client Access License (CAL) model in the same way that Exchange Server 2007 was licensed. There are three types of licenses:

Server Licenses A license must be assigned for each instance of the server software that is being run. The Server license is sold in two server editions: Standard Edition and Enterprise Edition. Client Access Licenses (CALs) Exchange 2010 also comes in two client access license (CAL) editions, which are referred to as a Standard CAL and an Enterprise CAL. You can mix and match the server editions with the CAL types. For example, you can use Enterprise CALs with Exchange 2010 Standard Edition. Similarly, you can use Standard CALs with Exchange 2010 Enterprise Edition. External Connector Licenses This license type allows an unlimited number of clients to access an Exchange server in scenarios where the number of CALs is uncertain. For more information about Exchange license types, see Licensing and Microsoft Exchange How to Buy.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Exchange Server Build Numbers and Release Dates

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2, Exchange Server 2010 SP1, Exchange Server 2010 Topic Last Modified: 2013-06-11 This topic provides you a central resource for build numbers and release dates for versions of Microsoft Exchange. You can use the information in this topic to verify the version of Exchange that is running in your organization. This topic is organized in sections that correspond to the major releases of Exchange. Each section lists the build numbers for each service pack level of the specific Exchange release. The For More Information section in this topic contains information to help you determine the build number and version of Exchange Server that youre running.

Exchange Server 2010

This section provides the build numbers and general release dates for each version of Microsoft Exchange Server 2010. To view the build number for the version of Exchange 2010 that youre running, run the following command in the Exchange Management Shell:

Get-ExchangeServer | fl name,edition,admindisplayversion

Note: After you install an update rollup for Exchange 2010, the version of Exchange Server isn't updated to show that the update rollup is installed. This issue occurs because the version number that is displayed by the Exchange Management Console or by other administrative mechanisms is obtained from the Exchange Server Object in Active Directory. For information about the servicing strategy for Exchange 2010, see Exchange 2010 Servicing. For more information about installing an update rollup for Exchange 2010, see Install the Latest Update Rollup for Exchange 2010.

Exchange Server 2010 SP3 build numbers

Product name Update Rollup 1 for Exchange Server 2010 SP3 Microsoft Exchange Server 2010 Service Pack 3 (SP3) Release date May 29, 2013 February 12, 2013 Build number 14.03.0146.000 14.03.0123.004

Exchange Server 2010 SP2 build numbers

Product name Update Rollup 6 for Microsoft Exchange Server 2010 SP2 Update Rollup 4 v2 for Exchange Server 2010 SP2 Update Rollup 4 for Exchange Server 2010 SP2 Update Rollup 3 for Exchange Server 2010 SP2 Update Rollup 2 for Exchange Server 2010 SP2 Update Rollup 1 for Exchange Server 2010 SP2 Exchange Server 2010 Service Pack 2 (SP2) Release date February 12, 2013 October 9, 2012 August 13, 2012 May 29, 2012 April 16, 2012 February 13, 2012 December 4, 2011 Build number 14.02.0342.003 14.02.0318.004 14.02.0318.002 14.02.0309.002 14.02.0298.004 14.02.0283.003 14.2.247.5

Exchange Server 2010 SP1 build numbers

Product name Update Rollup 7 v2 for Exchange Server 2010 SP1 Update Rollup 7 for Exchange Server 2010 SP1 Update Rollup 6 for Exchange Server 2010 SP1 Update Rollup 5 for Exchange Server 2010 SP1 Update Rollup 4 for Exchange Server 2010 SP1 Update Rollup 3 for Exchange Server 2010 SP1 Release date October 10, 2012 August 8, 2012 October 27, 2011 August 23, 2011 July 27, 2011 April 6, 2011 Build number 14.01.0421.002 14.01.0421.000 14.01.0355.002 14.1.339.1 14.1.323.6 14.01.0289.007

Update Rollup 2 for Exchange Server 2010 SP1 Update Rollup 1 for Exchange Server 2010 SP1 Exchange Server 2010 Service Pack 1 (SP1)

December 9, 2010 October 4, 2010 August 23, 2010

14.01.0270.001 14.1.255.2 14.01.0218.015

Exchange Server 2010 RTM build numbers

Product name Update Rollup 5 for Exchange Server 2010 Update Rollup 4 for Exchange Server 2010 Update Rollup 3 for Exchange Server 2010 Update Rollup 2 for Exchange Server 2010 Update Rollup 1 for Exchange Server 2010 Exchange Server 2010 Release date December 13, 2010 June 10, 2010 April 13, 2010 March 4, 2010 December 9, 2009 November 9, 2009 Build number 14.0.726.0 14.0.702.1 14.0.694.0 14.0.689.0 14.0.682.1 14.00.0639.021

Exchange Server 2007

The following table lists the build numbers and general release dates for each version of Microsoft Exchange Server 2007. The version information for Service Pack 1 (SP1) of Exchange Server 2007 is displayed correctly in the Exchange Management Console, in the Exchange Management Shell, and in the About Exchange Server 2007 Help dialog box. However, after you apply Exchange 2007 SP1 to an Edge Transport server that is running the release to manufacturing RTM version of Exchange 2007, the version information for the Edge Transport server isnt updated in the Exchange Management Console unless the Edge Transport server is resubscribed to the Active Directory site. This is because the Edge Transport server doesnt directly update Active Directory by using any configuration information. Instead, the version information for Edge Transport servers is recorded in Active Directory during the creation of an Edge Subscription. To view the build number for the version of Exchange 2007 that youre running, run the following command in the Shell:

Get-ExchangeServer | fl name,edition,admindisplayversion

Exchange Server 2007 SP3 build numbers

Product name Update Rollup 9 for Exchange Server 2007 SP3 Update Rollup 8-v3 for Exchange Server 2007 SP3 Update Rollup 8v2 for Exchange Server 2007 SP3 Update Rollup 8 for Exchange Server 2007 SP3 Update Rollup 7 for Exchange Server 2007 SP3 Update Rollup 6 for Exchange Server 2007 SP3 Update Rollup 5 for Exchange Server 2007 SP3 Update Rollup 4 for Exchange Server 2007 SP3 Update Rollup 3-v2 for Exchange Server 2007 SP3 Update Rollup 2 for Exchange Server 2007 SP3 Update Rollup 1 for Exchange Server 2007 SP3 Exchange Server 2007 SP3 Release date December 10, 2012 November 13, 2012 October 9, 2012 August 13, 2012 April 16, 2012 January 26, 2012 September 21, 2011 May 28, 2011 March 30, 2011 December 10, 2010 September 9, 2010 June 7, 2010 Build number 08.03.0297.002 08.03.0279.006 08.03.0279.005 08.03.0279.003 08.03.0264.000 8.03.0245.002 8.03.0213.001 8.03.0192.001 8.03.0159.002 8.03.0137.003 8.03.0106.002 8.03.0083.006

Exchange Server 2007 SP2 build numbers

Product name Update Rollup 5 for Exchange Server 2007 SP2 Update Rollup 4 for Exchange Server 2007 SP2 Update Rollup 3 for Exchange Server 2007 SP2 Update Rollup 2 for Exchange Server 2007 SP2 Release date December 7, 2010 April 9, 2010 March 17, 2010 January 22, 2010 Build number 8.2.305.3 8.2.254.0 8.2.247.2 8.2.234.1

Update Rollup 1 for Exchange Server 2007 SP2 Exchange Server 2007 SP2

November 19, 2009 August 24, 2009

8.2.217.3 8.02.0176.002

Exchange Server 2007 SP1 build numbers

Product name Update Rollup 10 for Exchange Server 2007 SP1 Update Rollup 9 for Exchange Server 2007 SP1 Update Rollup 8 for Exchange Server 2007 SP1 Update Rollup 7 for Exchange Server 2007 SP1 Update Rollup 6 for Exchange Server 2007 SP1 Update Rollup 5 for Exchange Server 2007 SP1 Update Rollup 4 for Exchange Server 2007 SP1 Update Rollup 3 for Exchange Server 2007 SP1 Update Rollup 2 for Exchange Server 2007 SP1 Update Rollup 1 for Exchange Server 2007 SP1 Exchange Server 2007 SP1 Release date April 13, 2010 July 16, 2009 May 19, 2009 March 18, 2009 February 10, 2009 November 20, 2008 October 7, 2008 July 8, 2008 May 9, 2008 February 28, 2008 November 29, 2007 Build number 8.1.436.0 8.1.393.1 8.1.375.2 8.1.359.2 8.1.340.1 8.1.336.1 8.1.311.3 8.1.291.2 8.1.278.2 8.1.263.1 8.01.0240.006

Exchange Server 2007 RTM build numbers for update rollup packages
Product name Update Rollup 7 for Exchange Server 2007 Update Rollup 6 for Exchange Server 2007 Update Rollup 5 for Exchange Server 2007 Update Rollup 4 for Exchange Server 2007 Update Rollup 3 for Exchange Server 2007 Update Rollup 2 for Exchange Server 2007 Update Rollup 1 for Exchange Server 2007 Exchange Server 2007 Release date July 8, 2008 February 21, 2008 October 25, 2007 August 23, 2007 June 28, 2007 May 8, 2007 April 17, 2007 March 8, 2007 Build number 8.0.813.0 8.0.783.2 8.0.754.0 8.0.744.0 8.0.730.1 8.0.711.2 8.0.708.3 8.0.685.25

Exchange Server 2003

The following table lists the build numbers and general release dates for each version of Microsoft Exchange Server 2003. To view the build number of Exchange Server 2003, open the Properties dialog box of the server object.

Exchange Server 2003 build numbers

Product name Exchange Server 2003 post- SP2 Exchange Server 2003 post-SP2 Exchange Server 2003 SP2 Exchange Server 2003 Service Pack 1 Exchange Server 2003 Release date August 2008 March 2008 October 19, 2005 May25, 2004 September 28, 2003 Build number 6.5.7654.4 6.5.7653.33 6.5.7683 6.5.7226 6.5.6944

Exchange 2000 Server

The following table lists the build numbers and general release dates for each version of Microsoft Exchange 2000 Server. To view the build number of Exchange 2000 Server, open the Properties dialog box of the server object.

Exchange 2000 Server build numbers

Product name Exchange 2000 Server post-SP3 Exchange 2000 Server post-SP3 Exchange 2000 Server post-SP3 Exchange 2000 Server post-SP3 Exchange 2000 Server post-SP3 Exchange 2000 Server SP3 Exchange 2000 Server Service Pack 2 Exchange 2000 Server Service Pack 1 Exchange 2000 Server Release date August 2008 March 2008 August 2004 April 2004 September 2003 July 18, 2002 November 29, 2001 June 21, 2001 November 29, 2000 Build number 6.0.6620.7 6.0.6620.5 6.0.6603 6.0.6556 6.0.6487 6.0.6249 6.0.5762 6.0.4712 6.0.4417

Exchange Server 5.5

The following table lists the build numbers and general release dates for each version of Microsoft Exchange Server version 5.5.

Exchange Server 5.5 build numbers

Product name Exchange Server version 5.5 Service Pack 4 Exchange Server version 5.5 Service Pack 3 Exchange Server version 5.5 Service Pack 2 Exchange Server version 5.5 Service Pack 1 Exchange Server version 5.5 Release date November 1, 2000 September 9, 1999 December 23, 1998 August 5, 1998 February 3, 1998 Build number 5.5.2653 5.5.2650 5.5.2448 5.5.2232 5.5.1960

Exchange Server 5.0

The following table lists the build numbers and general release dates for each version of Microsoft Exchange Server 5.0.

Exchange Server 5.0 build numbers

Product name Exchange Server 5.0 Service Pack 2 Exchange Server 5.0 Service Pack 1 Exchange Server 5.0 Release date February 19, 1998 June 18, 1997 May 23, 1997 Build number 5.0.1460 5.0.1458 5.0.1457

Exchange Server 4.0

The following table lists the build numbers and general release dates for each version of Microsoft Exchange Server 4.0.

Exchange Server 4.0 build numbers

Product name Exchange Server 4.0 Service Pack 5 Exchange Server 4.0 Service Pack 4 Exchange Server 4.0 Service Pack 3 Exchange Server 4.0 Service Pack 2 Exchange Server 4.0 Service Pack 1 Exchange Server 4.0 Standard Edition Release date May5, 1998 March 28, 1997 October 29, 1996 July 19, 1996 May 1, 1996 June 11, 1996 Build number 4.0.996 4.0.995 4.0.994 4.0.993 4.0.838 4.0.837

For More Information

For more information about how to determine the build number and version of Microsoft Exchange that youre running, see Microsoft Knowledge Base article 152439, How to determine the version number, the build number, and the service pack level of Exchange Server. For more information about Exchange Server 2010 versions, see Exchange 2010: Editions and Versions. For more information about Exchange Server 2007 versions, see Exchange Server 2007: Platforms, Editions, and Versions. For more information about how to determine build numbers and version information after you install an update rollup, see the following:

Exchange 2010 After you install an update rollup for Exchange 2010, the version of Exchange Server isn't updated to show that the update rollup is installed. This issue occurs because the version number that is displayed by the Exchange Management Console or by other administrative mechanisms is obtained from the Exchange Server Object in Active Directory. Exchange 2007 See How to View the Exchange Server 2007 Version Number After You Install an Update Rollup.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Exchange 2010 Language Support

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 Microsoft Exchange Server 2010 has enhanced language support for both servers and clients. This topic provides information about language packs, including the specific languages that are supported for both servers and clients in Exchange 2010. Other topics in this section include:

Language Support for Exchange Management Interfaces Client Language Support for Outlook Client Languages for Outlook Web App Client Language Support for Unified Messaging

Exchange 2010 Language Packs

An Exchange 2010 language pack contains the necessary resources for a supported Exchange language. Language packs are installed during installation of Exchange 2010. Client and server language packs come grouped into a single bundle containing both client and server resource and support files. There are no performance issues with installing all the languages because they're just stored when not in use. For organizations that have users in multiple languages, we recommend that you do the following:

On Unified Messaging (UM) servers, only install the UM language pack that you need for your organization. The addition of extra UM language packs introduces more processing when the server builds speech grammar for each language.

UM Language Packs
For a specific language that's supported by Exchange 2010 Unified Messaging, UM language packs allow an Exchange 2010 Unified Messaging server to speak additional languages to callers and recognize other languages when callers use Automatic Speech Recognition (ASR) or when voice messages are transcribed. UM language packs contain:

Pre-recorded prompts, for example, "After the tone, please record your message. When youve finished recording, hang up, or press the # key for more options." in the language of the UM language pack. Grammar files that are used by a Unified Messaging server to look up the names of specific users in the directory in the language of the UM language pack. Text-to-Speech (TTS) translation so that content (for example, e-mail, calendar, or contact information) can be read to callers in the language of the UM language pack. Support for ASR, which allows callers to interact with Unified Messaging using the Voice User Interface (VUI) in the language of the UM language pack. Support for Voice Mail Preview, which allows users to read the transcript of voice mail messages in a specific language from within a supported e-mail client such as Microsoft Outlook or Outlook Web App. The U.S. English (en-US) language pack contains UM prompts, TTS, ASR, and Voice Mail Preview support for this language. Important: The UM language pack must only be installed as an add-in to Exchange 2010 Unified Messaging. For more information about installing UM language packs, see Install a Unified Messaging Language Pack on a UM Server.

Supported Server Languages for Exchange 2010

The following server languages are supported and available for Exchange 2010:

Chinese (Simplified) Chinese (Traditional) English French German Italian Japanese Korean Portuguese Russian Spanish Beginning in SP1 of Exchange 2010, the following additional languages are supported:

Arabic Hebrew

Supported Client Languages for Exchange 2010

The following client languages are supported and available for Exchange 2010: Note: The Windows Server 2008 operating system Multilingual User Interface (MUI) packs aren't needed for client localization. Chinese (Simplified) English French German Japanese Chinese (Traditional) Italian Korean Portuguese Russian Spanish Arabic Czech Danish Dutch Finnish Greek Hebrew Hungarian Norwegian Polish Portuguese (Portugal) Swedish Turkish Romanian Thai Filipino (Philippines) Hindi Indonesian Latvian Malay Ukrainian Vietnamese Bulgarian Croatian Estonian Lithuanian Serbian Slovak Slovenian Basque Catalan Chinese (Hong Kong S.A.R.) Persian Icelandic Kazakh Serbian (Cyrillic, Serbia) Urdu

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Language Support for Exchange Management Interfaces

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-02-16 Microsoft Exchange Server 2010 offers a fully localized administrative experience in many languages. Administrators can use the fully localized management interface to administer Exchange 2010 in their chosen language. This topic indicates the languages supported in each type of management interface.

Exchange Management Console and Exchange Management Shell

The following languages are supported in both the Exchange Management Console and the Exchange Management Shell:

Chinese (Simplified) Chinese (Traditional) English French German Italian Japanese Korean Portuguese Russian Spanish For Service Pack 1 (SP1) of Exchange Server 2010, the following additional languages are supported:

Arabic Hebrew

Exchange Control Panel

The Exchange Control Panel (ECP) is localized in the Exchange client languages. For more information about client language support, see Exchange 2010 Language Support.

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Client Language Support for Outlook

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-11-17 In Exchange Server 2010, there are 48 supported languages that Office Outlook 2007 users can use to access their Microsoft Exchange mailbox.

Outlook Client Access

The language of the Outlook user interface that an Outlook user sees, including the content generated by Exchange, depends on the following:

The language the user is using in Outlook Whether the language they're using in Outlook is supported by Exchange 2010 Whether the language they're using in Outlook has been configured to be available on the Exchange 2010 server Consider the following scenarios:

When an Outlook user who's set their language to <Language A> signs in to their Exchange 2010 mailbox and both Outlook and Exchange 2010 support the language the user has specified, <Language A>, the user will see all messages and Exchange-generated mailbox components, for example, the Inbox, in Language A. When an Outlook user who's set their language to <Language A> signs in to their Exchange 2010 mailbox that's been set to <Language B>, the Outlook user will see the Outlook user interface in Language A, but will see the content generated by Exchange. For example, by default, folder names such as Inbox, Deleted Items, and Sent Items display in <Language B>. You can change the Exchange mailbox language setting on the server using Exchange Management Console or the Exchange Management Shell. For information about how to use the Shell to change the language setting for a mailbox on a server, see Set-MailboxRegionalConfiguration.

Supported Languages for Components and Features of Exchange 2010

The following table includes information about the languages that are supported for client and administrative features in Exchange 2010.

Supported languages for Exchange Server 2010

Language Arabic Basque Bulgarian Catalan Chinese (Cantonese) Chinese (Hong Kong) Chinese (Mandarin) Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English English English Estonian Filipino (Tagalog) Country/Region Saudi Arabia Spain Bulgaria Spain China China China China Taiwan Croatia Czech Republic Denmark Netherlands Australia United Kingdom United States Estonia Philippines Outlook 2007 client support Available Available Available Available Available Available UM language only Available Available Available Available Available Available UM language only UM language only Available Available Available

Finnish French French German Greek Hebrew Hindi Hungarian Icelandic Indonesian (Bahasa) Italian Japanese Kazakh Korean Latvian Lithuanian Malay Norwegian (Bokmal) Persian (Farsi) Polish Portuguese Portuguese Romanian Russian Serbian (Cyrillic) Slovak Slovenian Spanish Spanish Swedish Thai Turkish Ukrainian Urdu Vietnamese

Finland Canada France Germany Greece Israel India Hungary Iceland Indonesia Italy Japan Kazakhstan Korea Latvia Lithuania Malaysia Norway Iran Poland Brazil Portugal Romania Russia Serbia Slovakia Slovenia Spain Mexico Sweden Thailand Turkey Ukraine Pakistan Vietnam

Available UM language only Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available UM language only Available Available Available Available Available Available

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Client Languages for Outlook Web App

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-09-07 The Exchange 2010 Outlook Web App user interface is available in 54 languages. For more information about the languages that are supported in Outlook Web App, see Configure Language Settings for Outlook Web App. Contents Language and Locale Outlook Web App Spelling Checker Supported Languages for Components and Features of Exchange 2010

Language and Locale

There are three language settings that you can configure for Outlook Web App.

The sign-in and error language setting applies to individual Outlook Web App virtual directories. The sign-in and error language is the language that will be used for errors and the forms-based authentication sign-in page. If a value isn't set for this language, the default value is 0. This means that the default sign-in and error language isn't defined. If the sign-in and error language isn't defined, Outlook Web App will default first to the language set on the Web browser on the client computer. If the language set on the Web browser on the client computer isn't supported by Outlook Web App, Outlook Web App will use the language of the Client Access server. The default client language setting applies to individual Outlook Web App virtual directories. The default client language is the client language that's used by Outlook Web App unless the user uses Regional Settings in Outlook Web App to change the language and time zone. The default value for this setting is 0. This means the default client language isn't defined. If the default client language isn't defined, users will be prompted to choose a language and time zone the first time that they sign in to Outlook Web App. If the default client language value is defined, users won't be prompted to choose a language and the Outlook Web App time zone will use the time zone of the Client Access server. Defining the default client language causes the default folders to be renamed based on the specified language. Users can change the client language and time zone by using Regional Settings in Outlook Web App and can rename the default folders after they sign in. The client languages are set on individual mailboxes and affect the language that's used in Outlook and Outlook Web App. If multiple languages are configured, the first language in the list that's supported by the Web browser will be used. If none of the languages in the default languages list is supported by the Web browser, the Client Access server language will be used.

Outlook Web App Spelling Checker

In Exchange 2010 Outlook Web App, users can check spelling in 16 languages. Return to top

Supported Languages for Components and Features of Exchange 2010

The following table includes information about the availability and language support for the client and administrative features in Exchange 2010.

Language Arabic Basque Bulgarian Catalan Chinese (Hong Kong) Chinese (Simplified) Chinese (Traditional) Croatian Czech

Country/Region Saudi Arabia Spain Bulgaria Spain China China Taiwan Croatia Czech Republic

Outlook Web App - user interface Available Available Available Available Available Available Available Available Available

Outlook Web App - spelling checker Available

Danish Dutch English English English English English Estonian Filipino (Tagalog) Finnish French French Galician German Greek Hebrew Hindi Hungarian Icelandic Indonesian (Bahasa) Italian Japanese Kazakh Korean Latvian Lithuanian Malay Norwegian (Bokmal) Persian (Farsi) Polish Portuguese Portuguese Romanian Russian Serbian (Cyrillic) Serbian (Latin) Slovak Slovenian

Denmark Netherlands Australia United Kingdom Canada India United States Estonia Philippines Finland Canada France Spain Germany Greece Israel India Hungary Iceland Indonesia Italy Japan Kazakhstan Korea Latvia Lithuania Malaysia Norway Iran Poland Brazil Portugal Romania Russia Serbia Serbia Slovakia Slovenia

Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available

Available Available Available Available

Available

Available Available Available

Available

Available

Available

Available

Available

Available Available

Spanish Spanish Swedish Thai Turkish Ukrainian Urdu Vietnamese

Spain Mexico Sweden Thailand Turkey Ukraine Pakistan Vietnam

Available Available Available Available Available Available Available Available

Available

Available

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Client Language Support for Unified Messaging

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2013-03-21 Microsoft Exchange Unified Messaging language packs are version-specific and platform-specific. Since Exchange Server 2007, there have been separate releases for UM language packs, including Exchange 2007 RTM, Exchange 2007 SP1, SP2, and SP3, the RTM version of Exchange Server 2010, and Exchange 2010 SP1 and SP2. Both 32-bit and 64-bit downloads are available for some of these releases, but only 64-bit downloads are available for others. It's very important that you install the correct version and platform of the UM language packs on a UM server. Don't install UM language packs on a Unified Messaging server that's running an earlier version of Exchange or that's designed for a 32-bit platform. This topic describes Unified Messaging (UM) language packs and their availability in Microsoft Exchange Server 2010.

What Are Unified Messaging Language Packs?

Unified Messaging language packs allow an Exchange 2010 UM server to speak additional languages to callers and recognize other languages when callers use Automatic Speech Recognition (ASR) or when voice messages are transcribed. UM language packs contain:

Pre-recorded prompts in the language of the UM language pack, for example, "After the tone, please record your message. When youve finished recording, hang up, or press the # key for more options." Grammar files in the language of the UM language pack that are used by a UM server to look up the names of users in the directory. Text-to-Speech (TTS) translation so that content, such as e-mail, calendar, and contact information, can be read to callers in the language of the UM language pack. Support for ASR, which allows callers to interact with UM using the voice user interface (VUI) in the language of the UM language pack. In addition, UM language packs provide support for Voice Mail Preview, which allows users to quickly triage their voice messages by reading their transcripts from within a supported e-mail client such as Outlook or Outlook Web App. All UM language packs are single files that can be downloaded. These language packs include the pre-recorded prompts, grammar files, Text-to-Speech (TTS) translation, and ASR. However, not all the UM language packs contain support for Voice Mail Preview. The following UM language packs contain support for all the components and features, including Voice Mail Preview:

1. 2. 3. 4. 5. 6.

English (US) - (en-US) French (France) - (fr-FR) Italian - (it-IT)English (Canada) (en-CA) Polish (pl-PL) Portuguese (Portugal) (pt-PT) Spanish (Spain) (es-ES)

Note: For more information about Voice Mail Preview, see Voice Mail Preview for End Users By default, when you install the Exchange 2010 Unified Messaging server role, the server will send voice mail previews to UM-enabled users if a supported UM language pack is installed. There are Exchange 2010 Unified Messaging Voice Mail Preview partners that offer enhanced transcription support for the Voice Mail Preview feature. These partners employ people to correct voice mail transcriptions that were created using Automatic Speech Recognition (ASR). Each Voice Mail Preview partner must meet a set of requirements to be certified to interoperate with Exchange 2010 Unified Messaging. If you determine that the voice mail previews sent to your users aren't accurate enough, you can contact one of the certified Voice Mail Preview partners listed on the Microsoft PinPoint web page, and sign up with that partner at an additional cost. For more information, see Voice Mail Preview Advisor for Exchange 2010. The following table includes the supported languages for Exchange 2010 Unified Messaging.

Supported languages for Exchange 2010 UM language packs

Language Country/Region Culture ID Availability Prompts TexttoSpeech ASR Voice Mail Preview

Catalan Chinese (Hong Kong) Chinese (Simplified) Chinese (Traditional) Danish

Spain China

ca-ES zh-HK

Download available Download available

China

zh-CN

Download available

Taiwan

zh-TW

Download available

Denmark

da-DK

Download available

Dutch English English English

Netherlands Australia Canada India

nl-NL en-AU en-CA en-IN

Download available Download available Download available Download available Caution: Deploying the Exchange 2010 SP1 English (India) (en-IN) Unified Messaging language pack in organizations that include Exchange Server 2007 servers running on Windows Server 2003 will cause the Exchange 2007 servers to fail. Further details are contained in this Microsoft Knowledge Base article.

English English Finnish French French German Italian Japanese Korean Norwegian (Bokmal) Polish Portuguese Portuguese Russian Spanish Spanish Swedish Important:

United Kingdom United States Finland Canada France Germany Italy Japan Korea Norway

en-GB en-US fi-FL fr-CA fr-FR de-DE it-IT ja-JP ko-KR nb-NO

Download available Download available Download available Download available Download available Download available Download available Download available Download available Download available

Poland Brazil Portugal Russia Spain Mexico Sweden

pl-PL pt-BR pt-PT ru-RU es-ES es-MX sv-SE

Download available Download available Download available Download available Download available Download available Download available

To ensure that all Unified Messaging features are available in the UM language packs you install, you must install the Exchange 2010 Client and Server Language Pack on each UM server in the dial plan. If you dont install the Client and Server Language Pack, some features may not work as expected. Some features, like Voice Mail Preview, will work in the language thats configured on the dial plan but when only the UM language pack is installed. However, features like Outlook Voice Access and user interface text wont work in the language selected by the user without having both the UM language pack and the Client and Server Language Pack installed. The language pack bundle for Exchange Server 2010 Service Pack 2 (SP2) is integrated into the download for Exchange 2010 SP2. To download SP2 for Exchange 2010, see Microsoft Exchange Server 2010 Service Pack 2 (SP2). However, the language pack bundle for Exchange 2010 SP1 is still available. To download and install additional client and server language packs for Exchange 2010 SP1 on servers in your organization, see the Microsoft Exchange Server 2010 SP1 Language Pack Bundle.

Client Language Selection Process

Exchange 2010 UM language packs enable callers and Outlook Voice Access users to interact with the Unified Messaging system in multiple languages. After you install additional language packs on a Unified Messaging server, callers and Outlook Voice Access users can hear e-mail messages and interact with the Unified Messaging system, and Outlook Web App and Outlook 2010 users can view the transcript of a voice message using Voice Mail Preview in a specific language. To support a specific language, a UM client language pack for that language must be installed on each UM server in the UM dial plan. In some cases, if a UM language pack for a specific language hasnt been installed and isnt available, a client fallback language may be used instead of the language thats needed. For some languages, fallback UM client languages are available to be used, but for other languages, no fallback language is available. If there isnt a UM language pack installed for a specific language, and no fallback language is available for that language, en-US (US English) will be used. By default, the en-US UM language pack is installed on all Unified Messaging servers when you install the Unified Messaging server role. The en-US UM language pack cant be uninstalled. The following table includes a list of client languages and the fallback languages that are used when a specific UM language pack hasnt been installed on a Unified Messaging server.

Client Fallback Languages for UM

Language

Country/Region

Culture ID ca-ES zh-HK

First language chosen, if installed ca-ES zh-HK

Second language chosen, if installed en-US zh-CN

Third language chosen, if installed

Catalan Chinese (Hong Kong) Chinese (Simplified) Chinese (Traditional) Danish Dutch English English English English English Finnish French French German Italian Japanese Korean Norwegian (Bokmal) Polish Portuguese Portuguese Russian Spanish Spanish Swedish

Spain China

zh-TW

China Taiwan

zh-CN zh-TW

zh-CN zh-TW

zh-HK zh-HK

zh-TW zh-CN

Denmark Netherlands Australia Canada India United Kingdom United States Finland Canada France Germany Italy Japan Korea Norway

da-DK nl-NL en-AU en-CA en-IN en-GB en-US fi-FL fr-CA fr-FR de-DE it-IT ja-JP ko-KR nb-NO

da-DK nl-NL en-AU en-CA en-IN en-GB en-US fi-FL fr-CA fr-FR de-DE it-IT ja-JP ko-KR nb-NO

en-US en-US en-US en-US en-US en-US

en-US fr-FR fr-CA en-US en-US en-US en-US en-US en-US en-US

Poland Brazil Portugal Russia Spain Mexico Sweden

pl-PL pt-BR pt-PT ru-RU es-ES es-MX sv-SE

pl-PL pt-BR pt-PT ru-RU es-ES es-MX sv-SE

en-US pt-PT pt-BR en-US es-MX es-ES en-US en-US en-US en-US en-US

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Exchange 2010 Support for RFC Standards

Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-07-27 This topic is intended to be a reference for the Request for Comments (RFC) and other standards that are supported in Microsoft Exchange Server 2010. Although every effort has been made to verify this information, omission of an RFC from this list does not necessarily mean that Exchange does not fully or partially support the RFC. RFCs are guidelines, and they frequently contain two types of information: required and optional. Microsoft and other vendors may choose not to implement optional requirements, or they may interpret sections of RFCs differently. If you are experiencing a problem that you believe is caused because Exchange does not correctly support a particular RFC, open a support incident through Microsoft Customer Support Services (CSS). Important: The information that is contained in this topic represents the current view of Microsoft Corporation about the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, this information should not be interpreted to be a commitment on the part of Microsoft. Microsoft cannot guarantee the accuracy of any information that is presented in this topic after the date of publication. This topic is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT.

RFC Implementation Statements

All document references are listed in the following format:

Document/RFC: Document or RFC index Title: Description or title of document Updated by: RFCs that update this document Updates: RFCs that are updated by this document Obsoletes: RFCs that are replaced by this document or are obsolete Exchange 2010 specific: RFCs that are implemented by or supported by Exchange 2010; if applicable, the component and any other notes about support for the applicable RFC; links to additional information Note: For the purposes of this topic, "implemented" means that the RFC has been implemented natively within Exchange 2010, and "supported" means that a technology that is outside Exchange 2010 has implemented the RFC but that Exchange 2010 uses that implementation. Not all document references contain all fields that are shown in the sample format. In some cases, the information has been merged. Refer to the document source for the latest information.

World Wide Web Consortium (W3C) Standards

Note: The third-party Web site information in this topic is provided to help you find the technical information you need. The URLs are subject to change without notice.

Document: http://www.w3.org/TR/REC-html32 Title: HTML 3.2 Reference Specification Exchange 2010 specific: Implemented by Exchange 2010 Text Conversion component

Document: http://www.w3.org/TR/REC-html40 Title: HTML 4.01 Specification Exchange 2010 specific: Implemented by Exchange 2010 Text Conversion component

Document: http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ Title: Simple Object Access Protocol (SOAP) 1.1 Exchange 2010 specific: Partially implemented by Exchange Web Services

Document:Web Services-Interoperability Organization (WS-I) Standards Title: Basic Profile Version 1.0 Exchange 2010 specific: Implemented by Exchange 2010 Web Services

RFC: 1035 http://www.ietf.org/rfc/rfc1035.txt Title: Domain Names Implementation and Specification Updated by: 1101, 1183, 1348, 1876, 1982, 1995, 1996, 2065, 2136, 2137, 2181, 2308, 2535, 2845, 3425, 3658, 4033, 4034, 4035, 4343 Obsoletes: 882, 883, 973 Exchange 2010 specific: Supported by Exchange 2010

RFC: 1652 http://www.ietf.org/rfc/rfc1652.txt Title: SMTP Service Extension for 8bit-MIME transport Obsoletes: 1426 Exchange 2010 specific: Implemented by Exchange 2010 MIME Conversion Shared Components

RFC: 1731 http://www.ietf.org/rfc/rfc1731.txt Title: IMAP4 Authentication Mechanisms Exchange 2010 specific: Implemented by Exchange 2010 IMAP4 Service

RFC: 1740 http://www.ietf.org/rfc/rfc1740.txt Title: Mime Encapsulation of Macintosh files MacMIME Exchange 2010 specific: Implemented by Exchange 2010 MIME Conversion Shared Components

RFC: 1741 http://www.ietf.org/rfc/rfc1741.txt Title: MIME Content Type for BinHex Encoded Files Exchange 2010 specific: Implemented by Exchange 2010 MIME Conversion Shared Components

RFC: 1823 http://www.ietf.org/rfc/rfc1823.txt Title: The LDAP Application Program Interface Exchange 2010 specific: Supported by Exchange 2010 to communicate with Active Directory

RFC: 1870 http://www.ietf.org/rfc/rfc1870.txt Title: SMTP Service Extension for Message Size Declaration Obsoletes: 1653 Exchange 2010 specific: Implemented by Exchange 2010 Transport Service

RFC: 1896 http://www.ietf.org/rfc/rfc1896.txt Title: The text/enriched MIME Content-type Obsoletes: 1523, 1563 Exchange 2010 specific: Implemented by Exchange 2010 MIME Conversion Shared Components

RFC: 1939 http://www.ietf.org/rfc/rfc1939.txt Title: Post Office Protocol Version 3 Updated by: 1957, 2449 Obsoletes: 1725 Exchange 2010 specific: Implemented by Exchange 2010 POP3 Service

RFC: 2034 http://www.ietf.org/rfc/rfc2034.txt Title: SMTP Service Extension for Returning Enhanced Error Codes Exchange 2010 specific: Implemented by Exchange 2010 Transport Service

RFCs: 2045, 2046, 2047, 4289 2049, 4288 http://www.ietf.org/rfc/rfc2045.txt http://www.ietf.org/rfc/rfc2046.txt http://www.ietf.org/rfc/rfc2047.txt http://www.ietf.org/rfc/rfc4289.txt http://www.ietf.org/rfc/rfc2049.txt http://www.ietf.org/rfc/rfc4288.txt Titles: Multipurpose Internet Mail Extensions (MIME) [parts 1-5] Media Type Specifications and Registration Procedures

Updated by:2184, 2231, 2646, 3798 Obsoletes: 1521, 1522, 1590, 2048 Exchange 2010 specific: Implemented by Exchange 2010

RFC: 2088 http://www.ietf.org/rfc/rfc2088.txt Title: IMAP4 non-synchronizing literals Updated by:4466 Exchange 2010 specific: Implemented by Exchange 2010 IMAP4 Service

RFC: 2177 http://www.ietf.org/rfc/rfc2177.txt Title: IMAP4 IDLE command Exchange 2010 specific: Implemented by Exchange 2010 IMAP4 Service

RFC: 2181 http://www.ietf.org/rfc/rfc2181.txt Title: Clarifications to the DNS Specification Updated by: 2535, 4033, 4034, 4035, 4343 Updates: 1034, 1035, 1123 Exchange 2010 specific:Supported by Exchange 2010

RFC: 2183 http://www.ietf.org/rfc/rfc2183.txt Title: Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field Updated by: 2184, 2231 Updates: 1806 Exchange 2010 specific: Implemented by Exchange 2010 MIME Conversion Shared Components

RFC: 2231 http://www.ietf.org/rfc/rfc2231.txt Title: MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations Updates: 2045, 2047, 2183 Obsoletes: 2184 Exchange 2010 specific: Implemented by Exchange 2010 MIME Conversion Shared Components Note: Although RFC2231-encoded attachment file names are supported during inbound conversion, Exchange 2010 does not generate RFC2231-encoded content in MIME e-mail messages.

RFC: 2247 http://www.ietf.org/rfc/rfc2247.txt Title: Using Domains in LDAP/X.500 Distinguished Names Updated by: 4519, 4524 Exchange 2010 specific: Supported by Exchange 2010

RFC: 2311 http://www.ietf.org/rfc/rfc2311.txt Title: S/MIME Version 2 Message Specification Exchange 2010 specific: Implemented by Exchange 2010 Outlook Web App and S/MIME control

RFC: 2312 http://www.ietf.org/rfc/rfc2312.txt Title: S/MIME Version 2 Certificate Handling Exchange 2010 specific: Supported by Exchange 2010 Outlook Web App and S/MIME control

RFC: 2342 http://www.ietf.org/rfc/rfc2342.txt Title: IMAP4 Namespace Updated by: 4466 Exchange 2010 specific: Implemented by Exchange 2010 IMAP4 Service

RFC: 2387 http://www.ietf.org/rfc/rfc2387.txt Title: The MIME Multipart/Related Content-type Updated by: 2112 Exchange 2010 specific: Implemented by Exchange 2010 MIME Conversion Shared Components

RFC: 2445 http://www.ietf.org/rfc/rfc2445.txt

Title: Internet Calendaring and Scheduling Core Object Specification (iCalendar) Exchange 2010 specific: Implemented by Exchange 2010

RFC: 2446 http://www.ietf.org/rfc/rfc2446.txt Title: iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries Exchange 2010 specific: Implemented by Exchange 2010 (partially supported)

RFC: 2447 http://www.ietf.org/rfc/rfc2447.txt Title: iCalendar Message-Based Interoperability Protocol (iMIP) Exchange 2010 specific: Implemented by Exchange 2010 (partially supported)

RFC: 2449 http://www.ietf.org/rfc/rfc2449.txt Title: POP3 Extension Mechanism Updated by: 5034 Updates: 1939 Exchange 2010 specific: Implemented by Exchange 2010 POP3 Service

RFC: 2557 http://www.ietf.org/rfc/rfc2557.txt Title: MIME Encapsulation of Aggregate Documents, such as HTML (MHTML) Obsoletes: 2110 Exchange 2010 specific: Implemented by Exchange 2010 MIME Conversion Shared Components

RFC: 2595 http://www.ietf.org/rfc/rfc2595.txt Title: Using TLS with IMAP, POP3 and ACAP Updated by: 4616 Exchange 2010 specific: Implemented by Exchange 2010 IMAP4 and POP3 services; ACAP not supported

RFC: 2616 http://www.ietf.org/rfc/rfc2616.txt Title: Hypertext Transfer Protocol HTTP v1.1 Updated by: 2817 Obsoletes: 2068 Exchange 2010 specific: Implemented by Windows Server 2008; supported by Exchange 2010 Autodiscover Service and Exchange Web Services

RFC: 2617 http://www.ietf.org/rfc/rfc2617.txt Title: HTTP Authentication: Basic and Digest Access Authentication Obsoletes: 2069 Exchange 2010 specific: Supported by Exchange 2010 Autodiscover Service and Exchange Web Services

RFC: 2631 http://www.ietf.org/rfc/rfc2631.txt Title: Diffie-Hellman Key Agreement Method Exchange 2010 specific: Supported by Exchange 2010 Outlook Web App S/MIME Control

RFC: 2634 http://www.ietf.org/rfc/rfc2634.txt Title: Enhanced Security Services for S/MIME Exchange 2010 specific: Partially supported by Exchange 2010

RFC: 2782 http://www.ietf.org/rfc/rfc2782.txt Title: A DNS RR for specifying the location of services (DNS SRV) Obsoletes: 2052 Exchange 2010 specific: Supported by Exchange 2010

RFC: 2797 http://www.ietf.org/rfc/rfc2797.txt Title: Certificate Management Messages over CMS Exchange 2010 specific: Implemented by Exchange 2010 Outlook Web App S/MIME Control

RFC: 2821 http://www.ietf.org/rfc/rfc2821.txt Title: Simple Mail Transfer Protocol Updates: 1123

Obsoletes: 821, 974, 1869 Exchange 2010 specific: Implemented by Exchange 2010 Transport Service. Note: Note that Exchange 2010 does not currently support IP Literals (RFC 2821, Section 4.1.3).

RFC: 2822 http://www.ietf.org/rfc/rfc2822.txt Title: Internet Message Format Obsoletes: 822 Exchange 2010 specific: Implemented by Exchange 2010 MIME Conversion Shared Components

RFC: 3030 http://www.ietf.org/rfc/rfc3030.txt Obsoletes: 1830 Title: SMTP Service Extensions for Transmission of Large and Binary MIME Messages Exchange 2010 specific: Implemented by Exchange 2010 Transport Service

RFC: 3207 http://www.ietf.org/rfc/rfc3207.txt Title: SMTP Service Extension for Secure SMTP over Transport Layer Security Obsoletes: 2487 Exchange 2010 specific: Implemented by Exchange 2010 Transport Service

RFC: 3217 http://www.ietf.org/rfc/rfc3217.txt Title: Triple-DES and RC2 Key Wrapping Exchange 2010 specific: Implemented by Exchange 2010 Transport Service

RFC: 3278 http://www.ietf.org/rfc/rfc3278.txt Title: Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) Exchange 2010 specific: Supported by Exchange 2010 Outlook Web App and S/MIME control

RFC: 3370 http://www.ietf.org/rfc/rfc3370.txt Title: Cryptographic Message Syntax (CMS) Algorithms Obsoletes: 2630, 3211 Exchange 2010 specific: Supported by Exchange 2010 Outlook Web App and S/MIME control

RFC: 3394 http://www.ietf.org/rfc/rfc3394.txt Title: Advanced Encryption Standard (AES) Key Wrap Algorithm Exchange 2010 specific: Supported by Exchange 2010 Outlook Web App and S/MIME control

RFC: 3461 http://www.ietf.org/rfc/rfc3461.txt Title: Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) Obsoletes: 1891 Exchange 2010 specific: Implemented by Exchange 2010 Transport Service Note: For more information, see Understanding DSNs and NDRs

RFC: 3462 http://www.ietf.org/rfc/rfc3462.txt Title: The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages Obsoletes: 1892 Exchange 2010 specific: Partially implemented by Exchange 2010 Transport service

RFC: 3463 http://www.ietf.org/rfc/rfc3463.txt Title: Enhanced Mail System Status Codes Updated by: 3886, 4468, 4865, 4954 Obsoletes: 1893 Exchange 2010 specific:Implemented by Exchange 2010 Transport Service Note: For more information, see Understanding DSNs and NDRs

RFC: 3464 http://www.ietf.org/rfc/rfc3464.txt Title: An Extensible Message Format for Delivery Status Notifications Updated by: 4865 Obsoletes: 1894 Exchange 2010 specific: Implemented by Exchange 2010 Transport Service

RFC: 3501 http://www.ietf.org/rfc/rfc3501.txt Title: Internet Message Access Protocol Version 4rev1 Updated by: 4466, 4469, 4551, 5032, 5182 Obsoletes: 2060 Exchange 2010 specific: Implemented by Exchange 2010 (AUTH=PLAIN not supported)

RFC: 3503 http://www.ietf.org/rfc/rfc3503.txt Title: Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP). Exchange 2010 specific: Implemented by Exchange 2010 and adheres to the server implementation section

RFC: 3565 http://www.ietf.org/rfc/rfc3565.txt Title: Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS) Exchange 2010 specific: Supported by Exchange 2010 Outlook Web App and S/MIME control

RFC: 3629 http://www.ietf.org/rfc/rfc3629.txt Title: UTF-8, a transformation format of ISO 10646 Updates: 2279 Exchange 2010 specific: Supported by Exchange 2010

RFC: 3834 http://www.ietf.org/rfc/rfc3834.txt Title: Recommendations for Automatic Responses to Electronic Mail Exchange 2010 specific: Implemented by Exchange 2010 Mailbox Server

RFC: 3842 http://www.ietf.org/rfc/rfc3842.txt Title: A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP) Exchange 2010 specific: Implemented by Exchange 2010 Unified Messaging

RFC: 3850 http://www.ietf.org/rfc/rfc3850.txt Title: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling Obsoletes: 2632 Exchange 2010 specific: Supported by Exchange 2010 Outlook Web App and S/MIME control

RFC: 3851 http://www.ietf.org/rfc/rfc3851.txt Title: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification Obsoletes: 2633 Exchange 2010 specific: Implemented by Exchange 2010 Outlook Web App and S/MIME control

RFC: 3852 http://www.ietf.org/rfc/rfc3852.txt Title: Cryptographic Message Syntax (CMS) Updated by: 4853, 5083 Obsoletes: 3369 Exchange 2010 specific: Supported by Exchange 2010 Outlook Web App and S/MIME control

RFC: 3974 http://www.ietf.org/rfc/rfc3974.txt Title: SMTP Operational Experience in Mixed IPv4/v6 Environments Exchange 2010 specific: Supported by Exchange 2010 Transport service

RFC: 4120 http://www.ietf.org/rfc/rfc4120.txt Title: The Kerberos Network Authentication Service (V5) Updated by: 4537, 5021 Obsoletes: 1510 Exchange 2010 specific: Supported by Exchange 2010 Mailbox, Client Access, Hub Transport, and Unified Messaging (UM) servers that have the MSRPC protocol,

and by the Exchange POP3, IMAP4, and SMTP services

RFC: 4262 http://www.ietf.org/rfc/rfc4262.txt Title: X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities Exchange 2010 specific: Supported by Exchange 2010 Outlook Web App and S/MIME control

RFC: 4346 http://www.ietf.org/rfc/rfc4346.txt Title: The Transport Layer Security (TLS) Protocol Version 1.1 Updated by: 4366, 4680, 4681 Obsoletes: 2246 Exchange 2010 specific: Implemented by Exchange 2010 Transport Service, and by POP3, SMTP, and IMAP4 services

RFC: 4406 http://www.ietf.org/rfc/rfc4406.txt Title: Sender ID: Authenticating E-Mail Exchange 2010 specific: Partially implemented; Exchange 2010 does not support MTA forwarding of mail

RFC: 4409 http://www.ietf.org/rfc/rfc4409.txt Title: Message Submission for Mail Obsoletes: 2476 Exchange 2010 specific: Partially implemented; Exchange 2010 does not always return 554 DSN (for example, 550 5.7.1)

RFC: 4559 http://www.ietf.org/rfc/rfc4559.txt Title: SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows Exchange 2010 specific: Supported by Exchange 2010 Autodiscover Service and by Exchange Web Services

RFC: 4853 http://www.ietf.org/rfc/rfc4853.txt Title: Cryptographic Message Syntax (CMS) Multiple Signer Clarification Updates: 3852 Exchange 2010 specific: Implemented by Exchange 2010 Outlook Web Access and S/MIME control

RFC: 4954 http://www.ietf.org/rfc/rfc4954.txt Title: SMTP Service Extension for Authentication Updates: 3463 Obsoletes: 2554 Exchange 2010 specific: Implemented by Exchange 2010 Transport Service

RFC: 5008 http://www.ietf.org/rfc/rfc5008.txt Title: Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME) Exchange 2010 specific: Supported by Exchange 2010 Outlook Web App and S/MIME control

RFC: 1734 http://www.ietf.org/rfc/rfc1734.txt Title: POP3 Authentication command Exchange 2010 specific: Implemented by Exchange 2010 POP3 service Windows Integrated Authentication NTLM and GSSAPI

RFC: 5035 http://www.ietf.org/rfc/rfc5035.txt Title: Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility Updates: 2634 Exchange 2010 specific: Supported by Exchange 2010 Outlook Web App and by S/MIME control

For More Information

For more information about Exchange Server RFC and standards compliance in earlier versions of Exchange, see Microsoft Knowledge Base article 262986, Exchange Server RFC and standards compliance. For more information about RFCs, visit the following non-Microsoft Web sites: Note: The third-party Web site information in this topic is provided to help you find the technical information you need. The URLs are subject to change without notice.

RFC Editor The Internet Engineering Task Force (IETF) W3C World Wide Web Consortium International Telecommunication Union Ecma International

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.