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
Microsoft Exchange EdgeSync Service
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:
- 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.
- 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.
- 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 New-EdgeSubscription 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
- Set-SendConnector
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
- Topology data
- 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 | Value | ||
---|---|---|---|
Name |
EdgeSync - <Site Name> to Internet |
||
Address Space |
SMTP:*;100 |
||
Source Servers |
Edge Subscription name
|
||
Enabled |
True |
||
DNS Routing Enabled |
True |
||
Domain Secure Enabled (Mutual Auth TLS) |
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 | Value |
---|---|
Name |
EdgeSync - Inbound to <Site Name> |
Address Space |
SMTP:--;1 |
Source Servers |
Edge Subscription name |
Enabled |
True |
DNS Routing Enabled |
False |
Smart Hosts |
-- |
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.
Copy Code New-EdgeSubscription -FileData ([byte[]]$(Get-Content -Path "C:\EdgeServerSubscription.xml" -Encoding Byte -ReadCount 0)) -Site "Site-A" -CreateInboundSendConnector $false -CreateInternetSendConnector $true
- For the Edge Transport server that processes only inbound mail
flow, run the following command in the Shell on the Hub Transport
server.
Copy Code New-EdgeSubscription -FileData ([byte[]]$(Get-Content -Path "C:\EdgeServerSubscription.xml" -Encoding Byte -ReadCount 0)) -Site "Site-A" -CreateInboundSendConnector $true -CreateInternetSendConnector $false
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.
Copy Code | |
---|---|
New-EdgeSubscription -FileData ([byte[]]$(Get-Content -Path "C:\EdgeServerSubscription.xml" -Encoding Byte -ReadCount 0)) -Site "Site-A" -CreateInternetSendConnector $false |
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.
Copy Code | |
---|---|
New-SendConnector -Name "EdgeSync - Site-A to Internet" -Usage Custom -AddressSpaces SMTP:*;100 -DNSRoutingEnabled $false -SmartHosts 192.168.10.1 -SmartHostAuthMechanism None -SourceTransportServers EdgeSubscriptionName |
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.
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:
- 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 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.
- 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.
- 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 | Value | Description |
---|---|---|
Lock duration |
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. |
Option duration |
1 hour |
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. |
Lock renewal |
1 minute |
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. |
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.
- 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.
- 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.
- 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.
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:
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.