What’s good about EdgeSync?
- It makes design\configuration\administration a lot easier
Even if you have to modify the default send connector or add new send connectors you only need to do it once and the topology is pushed out to ADAM on the subscribed Edge Server. Rather than having to create routes from Hub to Edge and Edge outbound, EdgeSync enables you to create one route with the source as the Edge Subscription.
- It enables recipient filtering at the perimeter
EdgeSync will replicate recipient proxy addresses out to ADAM so that inbound email destined for addresses that do not appear in AD can be rejected at Edge.
- Safelist information is pushed out the Edge by EdgeSync
Safelist aggregation is the feature that combines data held within Outlook and Exchange. If you are using EdgeSync anti-spam safe recipients lists or safe senders Lists and contact data that Outlook users configure is pushed out to Edge. Apparently this is the most effective way of reducing false-positives in spam determination.
- Traffic between Hub and Edge is encrypted and authenticated by default
If you don’t subscribe your Edge servers the Edge’s certificate is not published in AD and so cannot be validated by the Hubs. Equally ADAM is not populated with the Hubs certificates for Edge to validate (largely because there will not be an ADAM to populate!). This means that you cannot establish ‘Direct Trust’ and Mutual TLS. To get around this you would configure your connectors to and from the Hub and Edge to use Basic authentication over TLS.
What’s not so good about EdgeSync?
- Updates can take time
The synchronisation schedule from Hub to Edge is as follows: configuration data every 1 hour, recipient data every 4 hours. This means that it may take up to 4 hours to replicate a recipient address to Edge. ..and some time longer for this same address to be loaded into memory on the Edge and therefore for emails to be accepted inbound. So if I create a new user account with a mailbox that new user will be able to send and receive internal emails very quickly. However if I am using EdgeSync the recipient address will not appear in cache on the Edge for some way beyond 4 hours. This is of course worst case and you can force the update process using the start-edgesynchronization commandlet, and then restart the transport service on the Edge to populate the cache, but you would probably only want to do this as a one off.
- Memory footprint on the hubs is not insignificant
As a guide "Each mail-enabled object causes approximately 4 KB of memory to be consumed by the EdgeSync process." (From the E2K7 help file.) So a directory containing 250,000 mail-enabled objects will consume about 1GB RAM on each Hub Transport server. Not huge but not insignificant. Incidentally the memory footprint on the Edge servers is much smaller.
- You might find yourself re-subscribing Edge servers to an AD Site more often than you thought
The circumstances when you would have to re-subscribe your Edge servers are as follows: 1-A new Hub Server has been added to the subscribed site. Any new Hub will not take part in EdgeSync because the Edge servers will not be aware of its existence. 2-You have rebuilt a failed Hub server. 3-The EdgeSync replication account credentials have been compromised. 4-You didn’t insert the license key on the Edge server until after you subscribed the server to the site. ..some of these are unlikely to occur but it is worth documenting and where possible scripting the procedure just in case.
I’ve been working on a design where the SLA’s for receiving inbound email for a newly created recipient were quite tight but on evaluating both approaches we decided quite quickly that the benefits of using EdgeSync easily outweigh the loss of functionality and issues that you may come across if you don’t…