The Exchange Server 2010 Edge Transport Server role is responsible for all incoming and outgoing internet email for an organization.
Typically deployed within a secure perimeter network, or DMZ, the Edge Transport Server is basically a smart host or SMTP relay server for the organization, and can protect from viruses, spam, and also perform other rule-based actions to control the flow of email in and out of the network.
What Needs to be Backed Up on Edge Transport Servers
To plan for backup and recovery of the Edge Transport server you first need to understand where the server stores its configuration and data.
Active Directory Lightweight Directory Service – each Edge Transport server runs its own instance of AD LDS, which is used to store a subset of information about recipients in the Exchange organization, as well as information about the connectors that are established between the Edge Transport server and the Hub Transport servers for mail flow. The AD LDS database and log files are stored on the file system of the server.
Edge Configuration – the Edge Transport server configuration can be exported to an XML file for cloning between servers and for recovery purposes. The Edge configuration file is stored on the file system of the server. This does not include the Edge Subscription information that connects the Edge Transport server to Hub Transport servers.
System State – the system state contains information such as service startup and dependency settings in the registry, which is important if any settings have been modified from the defaults. The System State is also important if extra third party applications or agents have been installed on the Edge Transport server, local security policies have been applied, administrative accounts or groups created or modified, and a range of other items that may be important in a recovery.
Other Files – other files such as transport queue databases and log files are also stored on the file system.
Planning the Edge Transport Server Backup
When you are planning the Edge Transport server backup strategy there are different approaches you can take depending on your requirements.
Backing up Everything
A full system backup of the server encompasses all of the required information for a recovery, however this takes longer to backup and consumes the most backup storage.
This makes it impractical if frequent backups are required throughout the day, for example in a high volume email environment the transport queue databases might be backed up every 5 minutes to reduce the risk of losing in-transit emails if the server crashed.
A full backup can also take longer to recover in some cases, however this is less of a concern if multiple Edge Transport servers are deployed.
Backing up the Minimum
A backup of just the Edge Transport configuration is the most efficient in terms of time frames and storage space, and can be run only when a configuration change has been made.
However the recovery time may be longer because a new host would need to be provisioned from scratch to import the config.
There may also be more manual intervention required because importing the configuration to a new server still requires the Edge Subscription to be set up again. In addition, this backup strategy does not protect the transport queue databases, log files, or any third party applications and agents installed on the server.
Backing Up and Restoring Edge Transport Servers
For the purposes of this demonstration I’ve made a few changes to a default Edge Transport server install on Windows Server 2008 R2.
The default log file paths have been modified:
An Edge Subscription is in place:
.NET Framework 4 has been installed via Microsoft Update:
Exporting/Importing the Edge Configuration
The Edge Configuration can be exported and imported using a script provided with Exchange Server 2010. The script is located in the \Scripts folder of your Exchange Server 2010 installation folder, which by default would be:
C:\Program Files\Microsoft\Exchange Server\V14\Scripts
On the Edge Transport server launch an Exchange Management Shell and run the script to export the Edge Configuration.
.\ExportEdgeConfig.ps1 -cloneConfigData C:\EdgeConfig\ex2-edgeconfig.xml Edge configuration is exported successfully to C:\EdgeConfig\ex2-edgeconfig.xml
For this demonstration the server operating system has been manually reinstalled to simulate a recovery scenario, and the Exchange Server 2010 reinstalled with the Edge Transport server role.
Note: the Edge Transport server can be a domain member however it is not a valid role for using Setup /m:RecoverServer to restore a failed server. In some scenarios you may encounter an error that “The Exchange Server is in an inconsistent state” when trying to reinstall the server. If you do then click here for the solution.
When the new Edge Transport server is ready you can import the Edge Configuration to it using a script that is once again located in your Exchange Server 2010 installation folder.
Launch the Exchange Management Shell, and then run the import script to validate that the configuration can be applied. This checks for such things as valid file system directories to confirm that that they can be recreated when the configuration is imported.
.\ImportEdgeConfig.ps1 -cloneConfigData C:\EdgeConfig\ex2-edgeconfig.xml -isImport $false -cloneConfigAnswer C:\EdgeConfig\ex2-answer.xml Warning:Passwords will be encrypted with the default script encryption key Validation succeeded for ConnectivityLogPath element of type DirectoryPath Validation succeeded for MessageTrackingLogPath element of type DirectoryPath Validation succeeded for PickupDirectoryPath element of type DirectoryPath Validation succeeded for PipelineTracingPath element of type DirectoryPath Validation succeeded for ReceiveProtocolLogPath element of type DirectoryPath Validation succeeded for ReplayDirectoryPath element of type DirectoryPath Validation succeeded for RoutingTableLogPath element of type DirectoryPath Validation succeeded for RootDropDirectoryPath element of type NullableDirectoryPath Validation succeeded for SendProtocolLogPath element of type DirectoryPath Validation succeeded for SourceIPAddress element of type IPAddress Validation succeeded for SourceIPAddress element of type IPAddress Validation succeeded for Bindings element of type Bindings Validation succeeded for Fqdn element of type FQDN Answer File is successfully created: C:\EdgeConfig\ex2-answer.xml
Next, import the configuration file by switching the -isImport parameter to $true.
.\ImportEdgeConfig.ps1 -cloneConfigData C:\EdgeConfig\ex2-edgeconfig.xml -isImport $true -cloneConfigAnswer C:\EdgeConfig\ex2-answer.xml Warning:Passwords will be encrypted with the default script encryption key WARNING: The contents of the pipeline tracing log may contain sensitive information. Make sure all content is either removed or secured appropriately. WARNING: The command completed successfully but no settings of 'exchangeserverpro.local' have been modified. WARNING: The following service restart is required for the change(s) to take effect : MSExchangeTransport Confirm Are you sure you want to perform this action? Removing Receive connector "EX2\Default internal receive connector EX2". [Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): a WARNING: The command completed successfully but no settings of 'IPAllowListConfig' have been modified. WARNING: The command completed successfully but no settings of 'IPAllowListProviderConfig' have been modified. WARNING: The command completed successfully but no settings of 'IPBlockListConfig' have been modified. WARNING: Edge Transport servers don't use the MaxDumpsterSizePerStorageGroup, MaxDumpsterTime, MaxReceiveSize, MaxRecipientEnvelopeLimit, and SupervisionTags parameters. Therefore, setting these parameters will have no effect. Importing Edge configuration information Succeeded.
Note the warning that the Transport service requires a restart. This does not happen automatically, so run the following command from the Exchange Management Shell.
Although the relevant Connectors are added to the Edge Transport server when the Edge Configuration is imported, they are not correctly set up on both ends (ie on the AD Site/Hub Transport servers as well). To do this you will need to re-run the Edge Subscription process.
Create an Edge Subscription file on the Edge Transport server by running the following command in an Exchange Management Shell.
New-EdgeSubscription -FileName c:\edgesubscription.xml Confirm If you create an Edge Subscription, this Edge Transport server will be managed via EdgeSync replication. As a result, any of the following objects that were created manually will be deleted: accepted domains, message classifications, remote domains, and Send connectors. After creating the Edge Subscription, you must manage these objects from inside the organization and allow EdgeSync to update the Edge Transport server. Also, the InternalSMTPServers list of the TransportConfig object will be overwritten during the synchronization process. EdgeSync requires that this Edge Transport server is able to resolve the FQDN of the Hub Transport servers in the Active Directory site to which the Edge Transport server is being subscribed, and those Hub Transport servers be able to resolve the FQDN of this Edge Transport server. You should complete the Edge Subscription inside the organization in the next "1440" minutes before the bootstrap account expires. [Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): y
Copy the XML file to an Exchange 2010 server in the organization. Launch the Exchange Management Console and navigate to Organization Management/Hub Transport. Start the New Edge Subscription task.
Select the Active Directory Site you wish to create the subscription with, and then browse and select the XML file that you copied from the Edge Transport server.
Click New to complete the Edge Subscription wizard.
The Edge Transport server role has now been recovered by:
- Reinstalling the operating system and Exchange Server 2010
- Importing a backup of the Edge Configuration
- Re-establishing the Edge Subscription
By only backing up the exported Edge Configuration file this technique takes up the least backup time and storage, however the restoration is more effort (note that the use of virtualization, templates or other automated build processes would speed it up to varying degrees).
- The customized log path settings were restored
- The Edge Subscription was manually recreated
- Additional applications were not recovered and need manual reinstallation
So depending on the server there will be additional effort to bring it back to full service, if only the Edge Configuration was ever backed up.
Full System Backup/Restore for Edge Transport Servers
For this demonstration I used Windows Server Backup to take a full system backup of the Edge Transport server to use for bare metal restore.
This backup takes longer than if you were only exporting and backing up the Edge Configuration on a regular basis. However the restore process is simpler and possibly even faster than the previous method, because the full system is being restored, although this would depending on your backup infrastructure and whether the restore media was on hand or needed to be brought in from offsite.
Once the full system restore is complete the server is ready to go, including the Exchange Server 2010 installation and all other applications and configurations on the server.
Although the Edge Subscription is restored by this method, if you test it from the Hub Transport server you may find that it is temporarily broken.
[PS] C:\>Test-EdgeSynchronization RunspaceId : 6143dd90-7b9b-40f2-8120-15e58a8e2f54 SyncStatus : Failed UtcNow : 9/08/2010 2:29:59 AM Name : EX2 LeaseHolder : CN=EX1,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Gr oups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=exchange serverpro,DC=local LeaseType : Option FailureDetail : The EdgeSync cookie has not been updated as expected. It may indicate EdgeSync has encoun tered synchronization errors. For more information, check the EdgeSync logs. LeaseExpiryUtc : 9/08/2010 2:46:13 AM LastSynchronizedUtc : 9/08/2010 1:46:13 AM TransportServerStatus : Skipped TransportConfigStatus : Skipped AcceptedDomainStatus : Skipped RemoteDomainStatus : Skipped SendConnectorStatus : Skipped MessageClassificationStatus : Skipped RecipientStatus : Skipped CredentialRecords : Number of credentials 3 CookieRecords : Number of cookies 2
You can usually fix this by simply restarting the EdgeSync service on the Hub Transport server.
[PS] C:\>Restart-Service MSExchangeEdgeSync
The Edge Subscription should now test successfully.
[PS] C:\>Test-EdgeSynchronization RunspaceId : 6143dd90-7b9b-40f2-8120-15e58a8e2f54 SyncStatus : Normal UtcNow : 9/08/2010 2:32:16 AM Name : EX2 LeaseHolder : CN=EX1,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Gr oups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=exchange serverpro,DC=local LeaseType : Option FailureDetail : LeaseExpiryUtc : 9/08/2010 3:30:15 AM LastSynchronizedUtc : 9/08/2010 2:30:15 AM TransportServerStatus : Skipped TransportConfigStatus : Skipped AcceptedDomainStatus : Skipped RemoteDomainStatus : Skipped SendConnectorStatus : Skipped MessageClassificationStatus : Skipped RecipientStatus : Skipped CredentialRecords : Number of credentials 3 CookieRecords : Number of cookies 2
The Edge Transport server role has now been recovered by performing a full system restore of the server.
- The custom log path settings were restored
- The Edge Subscription was maintained
- The additional applications were also recovered
By taking full system backups of the Edge Transport server the restoration process was simplified, however the backups themselves take up more time and backup storage.
As you can see there are pros and cons to each backup strategy for the Edge Transport server role in Exchange Server 2010. In most environments the full system backup/restore method works best as it simplifies almost every aspect of the process, with the only trade off being the extra time and storage capacity needed during backups. The config export/import method tends to be more suited to migrating the Edge Transport server to new hardware, or adding additional Edge Transport servers into the environment.