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 | Description |
---|---|
ms-Exch-Server-EKPK-Public-Key |
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. |
ms-Exch-EdgeSync-Credential |
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. |
ms-Exch-Edge-Sync-Lease |
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-Exch-Edge-Sync-Status |
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 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.