Overview
The Edge Synchronization monitoring test appears under Functionality for Exchange Mailbox servers.
Monitoring Benefit
The Edge Synchronization test verifies that EdgeSync is successfully pushing configuration and recipient data from the internal Exchange organisation out to the Edge Transport servers. It runs a full comparison, so it reports not just whether synchronisation is running but whether the data on both sides actually agrees.
EdgeSync failing rarely looks like an outage. Mail keeps flowing, and what users report instead is a scatter of symptoms that seem unrelated to each other: external senders getting bounce-backs for valid recipients, more spam arriving, disclaimers missing from outbound messages, new distribution groups unreachable from outside, NDRs for messages nobody sent. All of these come from an Edge server working correctly against configuration that has quietly gone stale.
That is what makes this test worth watching. The Edge server is the perimeter, and when its data ages, filtering decisions, recipient validation and routing all drift away from internal policy without anything appearing to be broken.
What EdgeSync keeps current
Synchronisation runs on two cadences: recipient data every 5 minutes, and configuration data every 60 minutes. Between them they keep the Edge server current on:
- Accepted domains, recipient metadata and distribution group membership — used for recipient validation and filtering
- Sender reputation data, IP block and allow lists, connection and recipient filtering settings
- Send connectors, remote domain settings and transport configuration
- Transport rules, including disclaimers and attachment filtering
EdgeSync writes this into AD LDS on the Edge Transport server, so problems with the AD LDS instance, its local replication or its storage surface here as synchronisation failures.
How the status is determined
The ENow Client runs a full comparison from the Exchange Mailbox server:
Test-EdgeSynchronization -FullCompareMode
The overall Sync Status maps to the indicator as follows:
| Sync Status | Indicator | Alert |
| Normal | Green | — |
| NoSyncConfigured | Grey | — |
| Warning | Yellow | Warning |
| Inconclusive | Yellow | Warning |
| Failed | Red | Critical |
| FailedUrgent | Red | Critical |
The comparison also returns a result for each synchronised area individually — accepted domains, message classifications, recipient, remote domain, send connector, transport config and transport server. Those map as follows:
| Result | Indicator | Alert |
| Synchronized | Green | — |
| Skipped | Green | — |
| NotStarted | Grey | — |
| InProgress | Grey | — |
| NotSynchronized | Yellow | Warning |
| DirectoryError | Red | Critical |
| Expired | Red | Critical |
A grey indicator is not a failure. NoSyncConfigured means no Edge Subscription exists, which is the correct state for an organisation that does not use Edge Transport servers. NotStarted and InProgress are transient states within a synchronisation cycle.
How do we verify the monitoring test results?
1. Run the same comparison from the Exchange Mailbox server. This returns the overall status and the per-area results the indicator is built from:
Test-EdgeSynchronization -FullCompareMode
2. Check the Edge Subscription itself. A subscription that has expired, or credentials that have become invalid, will stop synchronisation while leaving both servers otherwise healthy:
Get-EdgeSubscription | Format-List
An Expired result points here first. Edge Subscriptions use credentials generated when the subscription is created, and those can expire or become corrupted.
3. On a DirectoryError, look at AD LDS on the Edge server. EdgeSync writes into AD LDS, so a directory error is normally a problem with that instance rather than with Exchange. Check the AD LDS service, its event log and available storage on the Edge Transport server.
4. Check the secure channel. Synchronisation runs over an authenticated, encrypted channel. TLS negotiation failures and certificate problems between the Mailbox and Edge servers present as synchronisation failures with no obvious cause on either server alone.
5. Establish when the last successful sync happened. Because recipient data syncs every 5 minutes and configuration every 60, the age of the last success tells you how far the Edge server has drifted and which categories of data are affected.
Common warning or error results, and potential solutions
| Result | Potential solution |
| Failed or FailedUrgent | Synchronisation is not completing. Check the Edge Subscription, then the secure channel between the Mailbox and Edge servers, then AD LDS on the Edge server. |
| Expired | The Edge Subscription or its credentials have expired. The subscription needs to be recreated; note that this is done from the Edge server and then imported on the internal side. |
| DirectoryError | Check the AD LDS instance on the Edge Transport server — service state, local replication, schema and available storage. |
| NotSynchronized on recipient | Recipient data is stale. Expect external senders to receive NDRs for valid recipients, and newly created users or groups to be unreachable from outside. This is usually the first area customers notice. |
| NotSynchronized on transport config or send connector | Outbound routing on the Edge server is stale. Expect "550 Relay denied", "554 Transaction failed", routing loops, or mail stuck in queues after an internal routing or TLS change. |
| NotSynchronized on accepted domains | The Edge server does not know about a domain the organisation now accepts. External mail for that domain will be rejected. |
| Inconclusive | The comparison could not reach a definite answer. Re-run it manually; a persistent inconclusive result should be treated as a warning and investigated like a failure. |
| Grey — NoSyncConfigured | Expected where no Edge Subscription exists. If you do use Edge Transport servers, this means the subscription is missing entirely rather than failing. |
| Spam volumes increasing with no other symptom | Check this test. Sender reputation and filtering data are pushed by EdgeSync, and stale data weakens perimeter filtering while everything else keeps working. |
| Disclaimers or DLP rules missing from outbound mail | Transport rules are synchronised to Edge. A stale rule set means policy is not being enforced at the perimeter — worth treating as a compliance issue, not only a mail flow one. |
Enable or disable this test from the Exchange section of Alert Intelligence, under Exchange Server Edge Synchronization.
Comments
0 comments
Please sign in to leave a comment.