Troubleshooting GALsync Export Policies That Finish but Export No Data

Purpose

An export policy runs, reports Finished, and produces a data file containing no new objects — or stops running on its schedule altogether while still working when started by hand. Both point at the same place, and the status word is what makes the problem hard to see.

"Finished" does not mean "succeeded"

This is the first thing to understand. If GALsync cannot establish its Exchange Online PowerShell session, the policy is automatically cancelled — and the run still completes and reports a status. The evidence is in the log summary, not the status:

Analyzed: 0, Added: 0, Errors: 4

Zero objects analyzed is the signal. A policy that genuinely found nothing to export is rare; a policy that never got far enough to look is common. Always read the summary counts rather than the completion status.

Check the prerequisites

As of version 8.7, GALsync requires .NET Framework 4.8, Windows PowerShell 5.1, and the ExchangeOnlineManagement PowerShell module version 3.10.1 or later for Exchange Online PowerShell V3. The module must be installed on the GALsync server itself.

Get-Module -ListAvailable ExchangeOnlineManagement | Select-Object Name, Version
$PSVersionTable.PSVersion

Note that Windows PowerShell 5.1 is the requirement. If PowerShell 7 is also installed on the server, be aware of which one a given session is using when you test, because the two load assemblies differently.

The MSAL failure signature

Where the connection is failing on a dependency rather than a credential, the log carries a distinctive error:

Method not found: Microsoft.Identity.Client.PublicClientApplicationBuilder
Microsoft.Identity.Client.Broker.BrokerExtension.WithBroker

This is a version mismatch or missing dependency in Microsoft.Identity.Client, the MSAL library the ExchangeOnlineManagement module depends on. The usual causes:

• The module references an MSAL version that is not installed, is corrupted, or is incompatible with it.
• A conflicting copy of MSAL is present from another module or application on the same server.
• The session is running under PowerShell 7 or .NET Core and is not loading the expected MSAL assembly.

A plain Update-Module often does not clear this, because it can leave the older version in place alongside the new one. A clean reinstall is the more reliable step:

Uninstall-Module ExchangeOnlineManagement -AllVersions -Force
Install-Module ExchangeOnlineManagement -Force

Import-Module ExchangeOnlineManagement
Get-Module ExchangeOnlineManagement

Then test the connection the way the policy makes it, and confirm a query returns data rather than only that the connection opened.

Why it works manually and fails on schedule

This is the detail that resolves most of these cases, and it is easy to miss.

The GALsync Service exists only to execute scheduled policies, and every scheduled policy runs in the context of the user the service runs as. The service checks once a minute for enabled policies due to run, queues them, and runs them sequentially as that account.

So a module installed for your account — the default for Install-Module without -Scope AllUsers — is available when you test interactively and absent when the service runs the same policy. The symptom is exactly "it works when I run it by hand".

# Install for every account on the server, not just the current one
Install-Module ExchangeOnlineManagement -Force -Scope AllUsers

Check the same for any certificate the connection uses: a certificate in the current user's store is not in the service account's store.

A trap when collecting logs

When sending an Action → Export Status archive for analysis, open it and check the date of the newest log file before sending. Archives that do not contain logs from the failing run — because the run did not write one, or because the archive captured an older set — will be analysed against stale evidence, and several rounds can be lost establishing that the logs do not reflect the change just made.

If the newest log predates your most recent attempt, note that explicitly when you send it.

Separating token acquisition from session establishment

These are two different things and one can succeed while the other fails. A log can show the environment validated, the service running, the EWS URL correct at https://outlook.office365.com/EWS/Exchange.asmx, and token acquisition successful — and the PowerShell session still fails to establish.

Where that is the case, authentication and permissions are not the problem, and time spent re-checking the application registration is wasted. The fault is in the PowerShell layer: the module, its dependencies, or the account context it is loading under.

If the symptom persists

If the module is at 3.10.1 or later and installed for all users, a clean reinstall has been done, no conflicting MSAL is present, and the connection still fails from the service context, this is a case for support.

Send Action → Export Configuration and Action → Export Status from the exporting and importing servers, confirm the newest log covers the failing run, and include the exact Method not found text and the summary counts from that run.

References

• GALsync 8.7 Upgrade Instructions p.10 — .NET Framework 4.8, Windows PowerShell 5.1 and ExchangeOnlineManagement 3.10.1 requirements, and the module install command.
• GALsync 8.7 Manual p.77 — the GALsync Service; scheduled policies run in the context of the service account; the one-minute check and sequential execution queue.
• The current GALsync manual and upgrade instructions are published by NETsec at netsec.de.