EdgeSync Replication Data

Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2

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

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 anti-spam 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 organization-wide 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.