Setting Up Two-Way GALsync Between Multiple Tenants

Purpose

Several tenants need to see each other's address lists — after a group acquisition, or across a family of brands. Synchronization works in one direction but not the other, or works for some tenant pairs and not others. This article covers how a multi-tenant arrangement is actually built and the design decisions that determine whether it stays maintainable.

There is no two-way policy

The first thing to understand is that GALsync has no bidirectional policy. Every direction of synchronization is a separate export policy paired with a separate import policy. Two tenants exchanging address lists is two independent one-way flows, configured twice.

So "the sync is not going both directions" is usually not a fault. It is a configuration that was only ever built one way. Before troubleshooting, enumerate the policies and confirm a pair genuinely exists for each direction you expect.

With three or more tenants the arithmetic matters. Full mesh between n environments needs n × (n − 1) one-way flows: three tenants need six, four tenants need twelve. This is why a hub-and-spoke arrangement is the usual pattern beyond two environments — each spoke exchanges with the hub rather than with every other spoke.

The rule that prevents the worst failure

This one is worth designing around from the start, because violating it causes contacts to disappear on a cycle and no export setting prevents it.

One import policy per organizational unit. One export policy per Exchange Online target organization from the same source.

Where two import policies write into the same OU, each treats the OU's contents as its own to reconcile, and each deletes what the other created. The manual's worked example: policy 1 imports users A and B; policy 2 then imports users A and C into the same OU; user B is removed when policy 2 runs. The same applies to two export policies aimed at the same Exchange Online organization.

In a multi-tenant build this is easy to violate by accident, because the natural instinct is one OU called "External Contacts" holding everything. Give each source its own target container.

NETsec are explicit that splitting a single source's objects across two import policies into one destination is not viable for this reason — the two runs will each delete the other's work.

Deployment shape

A single GALsync server can run policies for several environments, or each environment can have its own. Both are supported and the choice is usually driven by where the data files need to travel and who administers each side.

Policies transfer data by mail, FTP or network share, with encryption, so the two sides do not need direct network access to each other — which is what makes a hub-and-spoke arrangement across organizational boundaries practical.

One constraint to plan for: all partners must run the same GALsync version. Synchronization between different versions is not supported, and data files carry the program version — anyone below 8.2.0 cannot import current files. In a multi-organization arrangement, upgrades have to be coordinated rather than done piecemeal.

Scoping each direction

Each flow should export only what the receiving side should see. The scoping mechanisms are covered in Controlling Which Objects GALsync and contactSync Synchronize, but two points matter particularly here.

Use dynamic distribution groups rather than recipient-type selection. Selection by recipient type — UserMailbox in particular — is no longer the recommended way to define an export scope. A dynamic distribution group evaluates membership at run time, which is what keeps a multi-tenant arrangement correct as people join and leave across several organizations at once. Where an existing policy uses recipient-type selection, migrating it to a group is worth doing before adding more flows on top.

Watch for objects that exist on both sides. In hybrid or multi-tenant arrangements a person can appear both as a directory-synchronized user object and as a GALsync-created contact, producing duplicate address-book entries that show different sets of direct reports. Exclude the object that should not be synchronized rather than trying to reconcile the two.

Where the imports land

An import policy writes mail-enabled contacts into a target you choose. If contacts are appearing in on-premises Active Directory when you expected them in Exchange Online, check which environment the import policy is configured against — this is a policy target question, not a product limitation.

Where the target is on-premises AD, confirm the target OU is excluded from directory synchronization if the tenant it feeds is also the source of those objects, or the contacts will synchronize up and collide with what they were copied from. See How to Export Microsoft 365 Contacts to On-Premises Active Directory Using GALsync.

Free/busy across tenants

Worth setting expectations on, because it is often assumed to come with the address list. Synchronizing the GAL does not make free/busy work. Cross-organization free/busy lookup requires the appropriate Microsoft federation or organization relationship between the environments, configured separately. GALsync creates the contacts; the availability path is a different mechanism.

Before you build

A short checklist that prevents most of the rework:

1. List every direction you need, as an explicit source-to-target pair.
2. Decide hub-and-spoke or mesh, and confirm the number of policy pairs that implies.
3. Assign each import its own target container.
4. Define each export's scope with a dynamic distribution group.
5. Confirm every partner is on the same GALsync version.
6. Set the export safety limits — Minimum objects and Maximum errors — on every export policy before the first live run.
7. Build and verify one direction end to end before creating the rest.

References

• GALsync 8.7 Manual p.12 — one import policy per organizational unit; one export policy per Exchange Online target; the worked deletion example.
• GALsync 8.7 Manual p.74 — policy components; transfer by mail, FTP or network share with encryption.
• GALsync 8.7 Manual p.167 — export safety limits.
• The current GALsync manual is published by NETsec at netsec.de.