Running GALsync Through an Exchange Online Migration

Purpose

Two organizations synchronize their address lists, and one or both start moving mailboxes to Exchange Online. Partway through, recently migrated users stop appearing at the partner. This article covers what changes as mailboxes move, and how to get through the transition without losing contacts.

What changes when a mailbox moves

The user does not disappear from the on-premises directory. They change type. An on-premises mailbox becomes a remote mailbox — an on-premises object pointing at a mailbox in Exchange Online.

That distinction is the whole problem. An export policy configured for on-premises mailboxes and not for remote mailboxes will stop including a user the moment their mailbox moves — and to the import, an object that is absent is an object that was deleted. The contact is removed at the partner.

So a migration can quietly delete contacts batch by batch, with every policy reporting success.

Before the first mailbox moves

Three things, in this order.

1. Set the export safety limits. On every export policy, set Minimum objects to transfer data file and Maximum errors to transfer data file. If a migration batch unexpectedly drops objects out of the export, the short file is held back rather than consumed. This is the single most valuable precaution and it costs nothing. See How to Prevent GALsync Contact Deletion During Export Errors.

2. Make remote mailboxes exportable. Add Remote User Mailbox to the Exportable RecipientTypeDetails list for each OU in the export scope, before the first batch moves rather than after. See Exporting Remote User Mailboxes.

3. Move scoping to a dynamic distribution group. A selection that enumerates objects, or selects by recipient type, needs revisiting every time the population changes — which during a migration is constantly. A dynamic distribution group evaluates membership at run time, so a mailbox that moves stays in scope without the policy being touched.

Check your version before you start

Version matters more here than in steady-state operation. Older releases handle migrated and hybrid recipients less well, and a migration is exactly the situation that exposes it — there is at least one case of synchronization of migrated users failing on an older 8.4 release and being resolved purely by both partners upgrading to a current 8.6 build.

Since all partners must run the same version, and an upgrade is a coordination exercise, do it before the migration rather than during. See Planning a GALsync or contactSync Upgrade.

During the migration

Watch the object count on every export. Not the success status — the count. It should stay roughly stable as mailboxes move, because a migrated user should leave one category and enter another rather than leave the export. A drop that tracks your migration batches means remote mailboxes are not being picked up.

Verify at the partner after the first batch. Pick two or three users who moved in the first batch and confirm their contacts still exist and still hold current addresses at the other side. Do this before the second batch, not after the tenth.

Expect the partner to see nothing wrong. Their import reports success. Contacts disappearing at their end is invisible to them until a user notices. You are the side that can detect this, so the checking is yours to do.

When both sides finish

Once both organizations are entirely in Exchange Online, the synchronization is Exchange Online to Exchange Online, and the on-premises considerations fall away. Worth revisiting at that point:

Whether the export scope still needs to include remote mailbox types.
Whether the environment configuration still references on-premises Exchange.
Whether authentication is certificate-based throughout — required from 8.6, and unavoidable given Microsoft's retirement of EWS for Exchange Online on 1 October 2026.

If migrated users have already stopped syncing

Confirm the contacts have been deleted at the partner rather than merely stale. These are different problems with different fixes.
Add Remote User Mailbox to the Exportable RecipientTypeDetails list for the relevant OUs.
Run the export manually and check the object count returns to what you expect.
Let the import run and confirm the contacts are recreated.
Warn the partner about cached Outlook entries. Recreated contacts carry a new legacyExchangeDN, so users who reply from autocomplete will get non-delivery reports until their cache refreshes. The central fix is restoring the old address as an X500 proxy address — see How GALsync Matches Contacts, and What Happens When the Match Breaks.

That last step is the one most often skipped, and it is what turns a quietly fixed problem into a visible one for the partner's users.

References

GALsync 8.7 Manual p.150 and p.153 — Exportable RecipientTypeDetails.
GALsync 8.7 Manual p.161 — selection by Recipient Type deprecated; dynamic distribution groups with Only Membership recommended.
GALsync 8.7 Manual p.167 — export safety limits.
GALsync 8.6.0 changelog — the EWS block for Exchange Online from 1 October 2026.
The current GALsync manual is published by NETsec at netsec.de.

Articles in this section