Why Objects Are Missing from a GALsync Export

Purpose

An export runs successfully but some objects are not in the data file, or the set changes between runs without anyone changing the policy. There are three distinct causes, and they are easy to mistake for one another because the symptom is identical.

Cause 1: the search result cap

This is the one that catches people, because nothing reports an error.

When objects are selected through the Search dialog, there is a maximum Results setting that defaults to 500. The default exists to prevent long-running searches. The consequence is documented plainly in the manual: if your result is larger than the given value, the objects that were not listed are not included in the policy.

Objects beyond the cap are silently absent from the policy. No error, no warning in the run. If you are exporting more than 500 objects and selected them through a search, raise this value before anything else.

Inserting an asterisk (*) queries for all objects of the selected recipient types — but the result cap still applies to what comes back.

Cause 2: RecipientTypeDetails not on the exportable list

GALsync exports objects whose msExchRecipientTypeDetails / RecipientTypeDetails property holds one of the values on the Exportable RecipientTypeDetails list — or whose property has not been set at all.

An object carrying a recipient type that is not on that list is not exported. The list can be modified with the Add/Remove RecipientTypeDetails control on the policy.

The manual carries an explicit warning about doing so, worth quoting in substance: for recipient types not present on the default list, GALsync does not check whether they are present or useful in your environment. Verification is left to the administrator, deliberately, so that as many scenarios as possible are supported. The disadvantage is that the list can be misconfigured and produce undesirable results.

So adding a recipient type is not validated for you. Add one only when you know the objects in question actually carry it, and confirm the exported count afterwards.

# See which recipient types your intended objects actually have
Get-Recipient -ResultSize Unlimited |
    Group-Object RecipientTypeDetails |
    Select-Object Name, Count |
    Sort-Object Count -Descending

Cause 3: static selection drifting out of date

Where objects are picked individually, or by a recipient-type selection, the set is fixed at the time it was configured. People joining, leaving or changing type afterwards are not reflected until someone edits the policy.

This produces the most confusing version of the symptom: an export that was correct when built and quietly incomplete months later, with a set that appears to change for no reason as objects drift in and out of qualifying.

A dynamic distribution group is the more robust alternative. Membership is evaluated at run time from a filter, so it tracks the directory without the policy being touched. This is also why a dynamic distribution group is the usual recommendation when an export needs to follow a moving population — active and licensed mailboxes, a department, a site.

Where an existing policy selects by recipient type, migrating that selection to a dynamic distribution group is worth doing for the same reason.

Distinguishing them

Work in this order, because each check rules out a whole class of cause:

1. Compare the exported object count against the number you expect. If the shortfall is at or near a round number such as 500, suspect the result cap immediately.
2. Check whether the missing objects share a recipient type that the present ones do not. If they do, the Exportable RecipientTypeDetails list is the cause.
3. Check whether the missing objects have anything else in common — recently created, recently changed type, a different OU. If so, the selection is static and has drifted.
4. Check that the missing objects meet the basic requirements: users and groups need an SMTP proxy address; contacts need a target address. Objects without these are not exportable regardless of selection.

Why this matters beyond the missing objects

An incomplete export is not a read-only problem. Objects absent from the data file are, to the import, objects that no longer exist at the source — so the corresponding contacts are deleted in the target environment.

Set Minimum objects to transfer data file on every export policy so that an unexpectedly short file is held back rather than consumed. See How to Prevent GALsync Contact Deletion During Export Errors.

For the exclusion side of scoping — stopping objects synchronizing on purpose — see Controlling Which Objects GALsync and contactSync Synchronize.

References

• GALsync 8.7 Manual p.150 and p.153 — Exportable RecipientTypeDetails; which objects are exported, the Add/Remove control, and the warning that added types are not validated.
• GALsync 8.7 Manual p.158 — the Search dialog, the asterisk wildcard, and the maximum Results default of 500 with objects beyond it excluded from the policy.
• GALsync 8.7 Manual p.167 — SMTP proxy and target address requirements; export safety limits.
• The current GALsync manual is published by NETsec at netsec.de.