GALsync Writes a Contact's Attributes onto the Wrong Object

Purpose

A synchronized contact in the partner environment shows another person's display name and attributes. Correcting it by hand works until the next run, when GALsync reverts it. In a cross-tenant arrangement this can be mistaken for a data problem at the source; it is not. This article explains the mechanism, the version that addresses it, and — importantly — why upgrading alone is not sufficient.

What is happening

GALsync matches a data file object against existing objects in the target environment using several criteria, not one. In addition to the primary SMTP address, matching can occur on an old primary SMTP address, a secondary SMTP address, the original SMTP address held in the source domain value, and the targetAddress.

That breadth is deliberate — it is what allows GALsync to keep matching an object through renames and address changes. The failure mode is that one source object can match two different target objects under two different criteria. With no rule to arbitrate, the run is not deterministic: attributes can land on the wrong object, and null reference errors can occur.

Entra ID guest users are the specific hazard. A guest user carrying an original SMTP address in its source domain value can match a source object that also matches the correct contact. The guest user is the object that then receives the wrong identity.

The reversion is the tell: if hand-correcting a display name works and is undone at the next run, GALsync is authoritative for that object and believes the value it is writing is correct.

The product fix, and its limits

A matching conflict resolution mechanism was introduced from version 8.5.2. Where two or more target objects match one data file object, it prioritises one based on matching type, and discards the others with a warning rather than processing them — which removes the null reference errors and makes the policy run deterministically. Discarded contacts and groups are marked for deletion, and the source domain value is truncated to the DN part.

Three limits matter and are easy to miss:

1. Every environment in the synchronization scheme must be on 8.5.2 or later. A single partner below that version reintroduces the defect for everyone in the mesh. This is a fleet-coordination problem, not a per-installation one.
2. Objects already damaged are not always repaired automatically by the upgrade. Existing wrong-identity objects can persist and need manual correction.
3. Mail users and guest users that were marked for synchronization but are no longer synchronized, and were not deleted by GALsync, can keep the problem alive even after every environment is upgraded.

So "upgrade and it goes away" is not an accurate summary, and treating it that way is how this recurs after a remediation that appeared to succeed.

Repairing an object by hand

For objects still carrying a corrupted match after the upgrade, the source domain value in the custom attribute is truncated so that only the part before the first pipe character remains.

A value of this shape:

CN=john.doe,DC=example,DC=onmicrosoft,DC=com|SMTP:john.doe@example.com|originalRecipientTypeDetails:UserMailbox|originalObjectClass:top;person;organizationalPerson;user

becomes:

CN=john.doe,DC=example,DC=onmicrosoft,DC=com

The attribute is the source domain property — by default CustomAttribute9 in Exchange Online or ExtensionAttribute9 on-premises.

# Inspect the current value
Get-Recipient -Identity <object> | Select-Object Name, RecipientTypeDetails, CustomAttribute9

# Truncate to the part before the first pipe
$r = Get-Recipient -Identity <object>
$new = ($r.CustomAttribute9 -split '\|')[0]
Set-MailContact -Identity <object> -CustomAttribute9 $new

Verify each change before moving to the next. Use the correct cmdlet for the object type — Set-MailContact, Set-MailUser and so on — and record the original values first.

Clean up the objects GALsync will not touch

GALsync deletes unmatched contacts. It does not delete mail users, guest users or groups. Where objects of those types were once synchronized and are now orphaned, they remain in the target environment and continue to participate in matching.

Identify them and decide deliberately whether to remove them:

# Objects carrying a GALsync source domain value that are not contacts
Get-Recipient -ResultSize Unlimited -Filter { CustomAttribute9 -like "*DC=*" } |
    Where-Object { $_.RecipientTypeDetails -notlike "*MailContact*" } |
    Select-Object Name, RecipientTypeDetails, PrimarySmtpAddress, CustomAttribute9

Guest users deserve particular attention, since they are the object type most often implicated.

A remediation sequence that holds

1. Establish the version of every environment in the scheme, including partners you do not administer. Anything below 8.5.2 must be upgraded before the rest of this is worth doing.
2. Consider pausing imports from environments still on older versions until they are upgraded, so that remediated objects are not re-corrupted.
3. Upgrade all environments.
4. Identify objects still showing wrong attributes and repair their source domain values by hand.
5. Find and resolve orphaned mail users and guest users carrying source domain values.
6. Run one policy and verify against the specific objects that were wrong.
7. Re-verify after a second run, because the signature of this problem is a correction that reverts.

Step 7 is the one people skip. A single clean run does not prove the matching conflict is gone.

Watch for a different symptom appearing after remediation

Where an upgrade stops the wrong-attribute reversion but some contacts then stop being created or updated at all, that is a separate problem rather than an incomplete fix — and it has its own documented cause. See Synced Contacts Report Up to Date but Never Change: the Source Domain Problem, since truncating source domain values can move objects out of the set a policy considers its own.

References

• GALsync 8.7 Manual p.191–192 — matching behaviour and the source domain value; the effect of changing a primary SMTP address on matching.
• GALsync 8.7 Manual p.302 — match combinations and the match counters in the log summary and status notification email.
• GALsync version history — matching conflict resolution from 8.5.2.
• The current GALsync manual and version history are published by NETsec at netsec.de.