Understanding Edge Subscriptions
Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
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:
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.
Edge Subscription process
.gif "Edge subscription file import and export 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
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 | Value |
|---|---|
Name |
EdgeSync - <Site Name> to Internet |
Address Space |
SMTP:*;100 |
Source Servers |
Edge Subscription name Note The name of the Edge Subscription is the same as the name of the subscribed Edge Transport server. |
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.
New-EdgeSubscription -FileData ([byte[]]$(Get-Content -Path "C:\EdgeServerSubscription.xml" -Encoding Byte -ReadCount 0)) -Site "Site-A" -CreateInboundSendConnector $false -CreateInternetSendConnector $trueFor 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" -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.
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.
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.
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.
EdgeSync synchronization process
.gif "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.
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.