Purpose
The export runs and produces a data file, but the mail carrying it never leaves. A draft appears in the mailbox with no attachment, or a send times out. Confusingly, a test email may report an error and still arrive.
This article covers what the evidence actually points at, because the obvious first diagnosis is usually wrong.
The failure signature
In the log:
Source GALsyncLibrary.EWSManager.sendMail()
Message Error sending mail.
Exmessage The request failed. The operation has timed out
Exsource Microsoft.Exchange.WebServices
And behaviourally: an item appears in the Drafts folder, never sends, and has no attachment. That combination — a draft with no attachment plus an EWS timeout — is the identifying pattern.
What it is usually not
Three explanations present themselves first and are commonly wrong. Rule them out cheaply rather than investigating them at length.
It is usually not the EWS URL, Autodiscover, DNS or the firewall. These are the natural first suspects for a timeout against a web service, and they are worth one quick check. But a send that reaches the point of creating a draft has already connected.
It is usually not the product version. This failure has been reproduced on a clean current-version installation on a brand-new server. An out-of-date version is worth correcting on its own merits, but do not expect the upgrade to fix this.
A test email that errors has not necessarily failed. The test send can report a timeout and still deliver the message. Do not treat the error alone as proof the path is broken — check whether the message arrived.
What it usually is
The account and authentication method used to send. Where an on-premises account is sending over Exchange Web Services, this failure recurs across environments. Switching to certificate-based authentication with an account that has a cloud mailbox in Exchange Online has resolved it, with the test mail then sending and the export sending with its attachment.
The change is not a workaround, it is the direction of travel anyway:
- User-based authentication for Exchange Online has been removed as of version 8.6.
- Microsoft will begin blocking EWS requests to Exchange Online from 1 October 2026. Anything built on EWS against Exchange Online has a deadline.
See Entra App Registration Permissions for GALsync and contactSync for the configuration, and Renewing an Expired App Registration Certificate for the certificate itself.
Working through it
- Confirm the export produced a data file at all. Check the log summary counts. If nothing was produced, this is a different problem.
- Check the Drafts folder of the sending mailbox. A draft with no attachment confirms this pattern.
- Send a test email from the environment configuration — and check whether it arrived, regardless of what the dialog reports.
- Establish how the sending account authenticates. On-premises account over EWS is the configuration to move away from.
- Move to certificate-based authentication with an account holding a cloud mailbox, and re-test.
- Confirm the export now sends with its attachment, not merely that the test mail works.
Consider a different transfer method
Mail is not the only option. A policy can transfer the data file by mail, FTP or a network share, with encryption. Where the two sides share a file path, or where a single server handles both, changing the transfer method sidesteps mailbox sending entirely.
That is worth considering on its merits rather than only as an escape from this problem — particularly given the EWS deadline.
A licence caveat while testing
If you are testing with a trial key, its object limit can block a full export and make it look as though sending is still failing. Confirm you are testing with a licence that covers your object count before drawing conclusions.
On Exchange Server SE
Where this appears after an upgrade to Exchange Server Subscription Edition, the timing is suggestive but the evidence does not support blaming the Exchange version — the same failure occurs on other on-premises versions using the same authentication path, and it resolves by changing authentication rather than by changing Exchange. If you need a definitive statement on supported Exchange versions for your GALsync release, that is worth confirming with support rather than inferring.
What to send if it persists
Collect Action → Export Configuration and Action → Export Status from both servers, and include:
- The full
EWSManager.sendMail()entry with its Exmessage and stack. - Whether a draft is created, and whether it has an attachment.
- Whether the test email arrives despite any error shown.
- How the sending account authenticates, and whether its mailbox is on-premises or in Exchange Online.
See Collecting GALsync and contactSync Logs for Support.
References
- GALsync 8.7 Manual p.74 — transfer by mail, FTP or network share with encryption.
- GALsync 8.6.0 changelog — Microsoft will block EWS requests to Exchange Online from 1 October 2026; removal of user-based authentication.
- The current GALsync manual and version history are published by NETsec at netsec.de.
Comments
0 comments
Please sign in to leave a comment.