Controlling Which Objects GALsync and contactSync Synchronize

Purpose

Two questions come up constantly: how do I stop specific people synchronizing, and why are disabled or deprovisioned accounts still appearing in the partner's address list? The second has a documented answer that surprises people, so it is worth stating first.

Account status is not a filter

GALsync exports all mailboxes and mail-enabled objects regardless of whether the account is enabled or disabled. That is documented behaviour, not a defect. The only hard requirements are that users and groups must have an SMTP proxy address value, and contacts must have a target address value.

The practical consequence: disabling an account in the source directory does nothing on its own. The contact stays in the partner's environment, because as far as GALsync is concerned the object still exists and still qualifies. To stop an object synchronizing, it has to leave the export's scope — by being removed from the selection, or by matching an exclusion rule.

This also explains the related question of soft-deleted Microsoft 365 accounts. Until the object is genuinely gone from the source, or excluded, it remains in the export.

Three ways to control scope

1. The selection itself

What an export policy selects — organizational units, groups, or dynamic distribution groups — is the primary control. Of these, dynamic distribution groups are the most robust for ongoing synchronization, because membership is evaluated at run time from a filter rather than maintained as a list.

This is what makes them the practical answer to "exclude inactive accounts": a dynamic distribution group whose filter selects only active, licensed mailboxes will stop returning an account when it stops qualifying, without anyone editing the policy. GALsync is not evaluating account status — the group is.

2. Export Settings: Object Filter

An export policy's Object Filter excludes objects that meet any of its conditions. Each condition names a property, a comparison operator and a value. Every object is analysed during export, and if at least one condition is fulfilled, the object is not exported.

Conditions are an OR, not an AND — a single match is enough to exclude. That is usually what people want, but it catches those who build several conditions expecting them to narrow the set collectively.

3. The exclusion marks

GALsync ships default Object Filter rules based on a custom-attribute mark, which is the per-object exclusion mechanism:

• On-premises: extensionAttribute1 to extensionAttribute15 containing nogalsync
• Exchange Online: customAttribute1 to customAttribute15 containing nogalsync

Two further default rules ensure that MailUsers and GuestUsers marked for deletion are not exported.

Marking an individual object is the right tool for a handful of exceptions. For a category of people — contractors, unlicensed accounts, a whole site — a dynamic distribution group or an Object Filter condition scales better than attribute-marking each object.

# Exchange Online
Set-Mailbox -Identity <user> -CustomAttribute1 'nogalsync'

# On-premises
Set-ADUser -Identity <user> -Replace @{ extensionAttribute1 = 'nogalsync' }

The contactSync equivalents

contactSync uses the same idea with different marks, and it has two of them doing opposite jobs:

• NoContactSync excludes an object from being synchronized as a contact — it removes the person from the source set.
• NoMailboxSync excludes a mailbox from receiving synchronized contacts.

Both go in any custom attribute, on the same on-premises and Exchange Online attribute ranges. Choose by asking which side you are excluding: someone who should not appear in other people's contacts takes NoContactSync; someone who should not receive the shared set takes NoMailboxSync.

For excluding a category rather than individuals — unlicensed cloud accounts, for instance — a dynamic distribution group filtered to active mailboxes is the cleaner approach, for the same reason it is in GALsync.

What happens when an object leaves scope

This is the part worth thinking through before changing a filter.

An object that stops being exported is, from the import's point of view, indistinguishable from one deleted at the source — so the contact is deleted in the target environment. That is correct behaviour, and it is what you want when someone leaves. It is emphatically not what you want if you have just tightened a filter more than you intended.

Two safeguards are worth having in place before you experiment:

• Set Minimum objects to transfer data file on the export policy, so a filter change that unexpectedly removes most of the set holds the file back instead of shipping it. See How to Prevent GALsync Contact Deletion During Export Errors.
• Compare the exported object count before and after any filter change, before letting the import run.

Deleted and recreated contacts also get a new legacyExchangeDN, which breaks cached Outlook entries. See How GALsync Matches Contacts, and What Happens When the Match Breaks.

References

• GALsync 8.7 Manual p.167 — Disabled objects: all mailboxes and mail-enabled objects are exported regardless of enabled state; SMTP proxy and target address requirements.
• GALsync 8.7 Manual p.173 — Export Settings: Object Filter; conditions, the any-match rule, and the default nogalsync and marked-for-deletion rules.
• contactSync 8.7 Manual p.61 — the NoContactSync mark.
• contactSync 8.7 Manual p.113 — the NoMailboxSync mark.
• The current manuals are published by NETsec at netsec.de.