Installing, Configuring Exchange 2007 Edge Server (Part 2)

The EdgeSync service glues together the internal Exchange 2007 servers to the perimeter Edge servers. This is achieved whilst retaining the necessary isolation between the two network segments.

In Installing, Configuring Exchange 2007 Edge Server (Part 1) we started the installation of an Exchange 2007 Edge server at the DMZ.

So far we installed the Exchange Edge role on a standalone Windows 2003 server. The server is still not connected to the rest of the Exchange organization running internally. Indeed we could employ Edge as the perimeter server even if we were not running Exchange internally. As is, Edge only requires port 25 communications and the configuration of send/receive connectors, to act as a relay to any SMTP server.

However, quite obviously, Edge also includes special support for running together with an internal Exchange 2007 organization. This functionality is provided by the EdgeSync service. Running on an internal Hub transport server, EdgeSync pushes information to the Edge server. The following is some of the information transferred; more details are available from the article EdgeSync Replication Data:

• Email routing configuration such as the list of accepted domains and connector configuration.
• Recipient information that is especially useful for rejecting emails addressed to invalid recipients.
• Safe Sender lists configured at each of the recipient mailboxes.

Making this information available to the Edge server enables the immediate filtering of emails. Furthermore, once the system is deployed, an Administrator will be able to manage the Edge server from the internal network. Configuration changes are simply pushed by EdgeSync, reducing the need to log on to the Edge server directly.

All this is achieved without compromising the need for isolation. EdgeSync only requires the opening of an additional port at the firewall separating the internal and perimeter networks. This is port 50636, a custom secure LDAP port to which ADAM is listening.

Another point to notice is the fact that information only flows from the internal to the perimeter network and not the other way round. Again this meets our isolation requirements. If the information at the perimeter were to be poisoned, this information would not get propagated internally.

DNS Configuration

Before proceeding further we have to take care of name resolution. Both Edge and internal Hub servers need to be able to resolve each other's name through DNS. For this to work we will add host (A) records for each of the Edge/Hub transport servers.

In a typical DMZ configuration the perimeter and internal networks run on different subnets. In our case we have these settings:

Perimeter subnet: 192.168.0.0/255
Edge Server Name: abcd.exchinbox.local
Edge Server IP: 192.168.0.5

Internal subnet: 192.168.10.0/255
Hub Server Name: exchsrv.exchinbox.local
Hub Server IP: 192.168.10.60

We start from the internal DNS server. This is the one used by the Hub transport. Thus we add an A record for the Edge server named 'abcd'. We add this under the Forward Lookup Zone for exchinbox.local.

We now test name resolution and port 25 connectivity. This telnet command will verify both:
telnet abcd 25

Note: If running Windows 2008, install the telnet client from Server Manager | Add Features, select the check box for the Telnet Client and complete the wizard.

Now we move to the perimeter network and create an A record for the Hub named 'exchsrv'. If the perimeter were running its own DNS server, we would create the A record there, as we did for the internal network. Otherwise we just edit the hosts file located under:
\system32\drivers\etc

Here we add the line:
192.168.10.60 exchsrv

We now perform the same telnet test to verify name resolution and connectivity from edge to hub:
telnet exchsrv 25

Creating an Edge Subscription

It is now time to setup EdgeSync. This process starts from the edge server machine. At the Exchange Management Shell we run:
New-EdgeSubscription -file c:\temp\EdgeSubscription.xml

The file parameter identifies the path where an Edge Subscription XML file is to be created.

On running the command we are greeted with a very informative warning that is worth reading:

"Creating an Edge Subscription makes the configuration of this Edge Transport server ready to be managed via EdgeSync. Any of the following types of objects that were created manually will be deleted: accepted domains; message classifications; remote domains; and Send connectors. Also, the InternalSMTPServers list of the TransportConfig object will be overwritten during the synchronization process. The Exchange Management Shell tasks that manage those types of objects will be locked out on this Edge Transport server. You must manage those objects from inside the organization and allow EdgeSync to update the Edge Transport server. EdgeSync requires that this Edge Transport server is able to resolve the fully qualified domain names (FQDN) of the Hub Transport servers in the Active Directory site to which the Edge Transport server is being subscribed. Those Hub Transport servers must 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."

Hitting 'Y' will complete this step and the Edge Subscription file is created. Here is what it looks like:

We now transfer this file to the Hub Transport server. Here at the Exchange Management Console under Organization | Hub Transport we select New Edge Subscription and follow the wizard that opens.

In the introductory step note the checkbox saying:
'Automatically create a Send connector for this Edge Subscription'

This will create the connectors necessary for emails to flow between Edge and Hub transports.

The final wizard step reminds us to open port 50636 for the EdgeSync service to be able to push information to ADAM.

"EdgeSync requires that the Hub Transport servers in Active Directory site Default-First-Site-Name must be able to resolve the IP address for abcd.exchinbox.local, and be able to connect to that host on ports 50636."

Completing the subscription, we can immediately have a look at the new configuration elements that were created. Under Organization | Hub Transport | Edge Subscriptions we find the registration of the 'abcd' server.

Under Organization | Hub Transport |Send Connectors we have two new send connectors:

EdgeSync in Action

In my test environment EdgeSync kicked off immediately and completed the first synchronization. However I did come across reports claiming that the Microsoft Exchange EdgeSync service needed a restart. Don't forget EdgeSync runs at the internal Hub Transport and this is where you will find the service.

Thereafter synchronization will follow a fixed schedule:
Every 1 hour - Configuration information
Every 4 hours - Recipient information
Every 5 minutes - Topology information

We can easily verify whether the first synchronization pushed the expected information to the Edge server. From the Edge server management console, we check the list of accepted domains that were configured internally.

While we are at the Edge server, we can verify if configuration changes were locked as promised earlier on creating the Edge Subscription. Here I tried to edit one of the send connectors and was promptly blocked:

"This task may not be run on an Edge Transport server that is subscribed to an Active Directory site. You must perform this operation on a Hub Transport server in the subscribed Active Directory site. The changes will be replicated to the Edge Transport server when synchronization next occurs."

Now let's see what happens when the configuration changes at the Hub Transport. Here at the "EdgeSync - Inbound to Default-First-Site-Name" Send Connector, I configured exchsrv.exchinbox.local as the smart host to be used by the Edge server for inbound emails.

This change won't be visible to the Edge server until the next synchronization cycle unless we force it to. From the Exchange Management Shell we first run:
Test-EdgeSynchronization

This returns a report showing that everything is synchronized except for the SendConnectorStatus.

Next we run:
Start-EdgeSynchronization

This will force an immediate synchronization pushing the new Send Connector settings to the Edge. Of course the same cmdlets also come very handy when troubleshooting.

Final Tips

With the Edge Server role, Exchange 2007 provides a good DMZ citizen that is able to satisfy the isolation restrictions imposed by the perimeter network. This is achieved whilst retaining a good level of integration.

EdgeSync provides the necessary link that allows us to manage the Edge server from the internal network. However it is important to understand the work that is going on behind the scene. If new recipient mailboxes are created or a new accepted domain is added, the Edge server won't know of these until synchronization kicks in. If this is an issue, we should force synchronization from the command shell with Start-EdgeSynchronization.

Of course apart for port 25 don't forget to open port 50636 for EdgeSync to work. EdgeSync traffic only flows from the Hub to the Edge transport. Thus we only need port 50636 open at the firewall separating the internal network from the perimeter (in that direction).

One of the areas where I see problems most often is name resolution. The Edge server needs to resolve the names of all hosts it will be interacting with, including those of the internal Hub transport. Same goes for the internal network. Here the Edge server name must also be resolvable through DNS.

Source: http://www.exchangeinbox.com/article.aspx?i=134