Purpose
An export policy against Exchange Online fails on object after object with a missing email address, even though the mailboxes plainly have addresses. This is a known defect in versions before 8.6, caused by changes on the Microsoft side, and the fix is a version upgrade — with one trap immediately afterwards.
The error
Two codes appear together, one per object, and both point at the same underlying failure:
Code 36007
Source GALsyncLibrary.EOObject.findSMTPAddress()
Message <object> (<guid>): Missing email address.
Code 36025
Source GALsyncLibrary.EOObject..ctor()
Message <object> (<guid>): RecipientType, object class or SMTP address is empty.
The distinguishing characteristic is that the objects are fine. Query the same mailbox manually through Exchange Online PowerShell and the recipient type and addresses come back populated. GALsync is not receiving what the tenant is returning.
This matters because it sends people to look for data problems in the directory, which is where the time goes. Before investigating any object, check the version.
The cause and the fix
This is a known issue in any GALsync version older than 8.6, resulting from changes Microsoft made to how these attributes are returned. Upgrading to 8.6 or later resolves it.
Confirm the platform prerequisites at the same time, since they changed across the same releases:
- 8.5 and later: .NET Framework 4.8 or later, Windows PowerShell 5.1, ExchangeOnlineManagement module 3.6 or later.
- 8.7: .NET Framework 4.8, Windows PowerShell 5.1, ExchangeOnlineManagement module 3.10.1 or later.
Get-Module -ListAvailable ExchangeOnlineManagement | Select-Object Name, Version, ModuleBase
$PSVersionTable.PSVersion
Install the module for all users, not just your own profile — scheduled policies run as the service account.
Request the new licence before you upgrade
This is the trap, and it turns a planned upgrade into an outage.
A licence issued for an earlier major version is not accepted by a later one. Upgrading from 8.4 to 8.6 with an 8.4 licence leaves every import and export policy failing until a current key is applied — so the fix for the export errors is immediately replaced by a different total failure.
Request the licence for the target version first, then upgrade. See GALsync Licensing: Delivery, Activation, Renewal and Upgrades.
Verifying against a single object
Before and after the upgrade, check one of the failing objects directly. If the manual query returns full attributes while the policy reports them empty, you are looking at this defect rather than a data problem:
Connect-ExchangeOnline -AppId <app-id> `
-CertificateThumbprint <thumbprint> `
-Organization <tenant>.onmicrosoft.com
Get-Recipient -Identity <object> |
Format-List Name, RecipientTypeDetails, PrimarySmtpAddress, EmailAddresses
Run this as the account the GALsync service runs as where you can, since a difference in context is itself a possible explanation.
If the errors persist on a current version
Where 8.6 or later is installed, the licence is current, the module meets the requirement, and objects still fail this way, the objects themselves are worth checking. Users and groups must have an SMTP proxy address value; contacts must have a target address value. Objects lacking these are genuinely not exportable.
Beyond that, collect Action → Export Configuration and Action → Export Status from both servers, confirm the newest log covers the failing run, and include the exact 36007 and 36025 lines with the object identifiers.
Related
- Why Objects Are Missing from a GALsync Export — when objects are absent rather than erroring.
- How to Prevent GALsync Contact Deletion During Export Errors — important here, because an export failing on many objects can produce a data file short enough to cause deletions at the target.
References
- GALsync 8.7 Upgrade Instructions p.10 — platform prerequisites by version.
- GALsync 8.7 Manual p.167 — SMTP proxy and target address requirements for exportable objects.
- The current GALsync manual, upgrade instructions and version history are published by NETsec at netsec.de.
Comments
0 comments
Please sign in to leave a comment.