Import Returns 0 Objects and Reports "Source uses an old program version"

Purpose

An import runs, reports 0 objects, and warns that the source uses an old program version — while both environments are demonstrably on the same current release. The version message is misleading, and chasing it wastes time on the wrong side of the synchronization.

What the message actually means

As of version 8.6, the program version is written into the data file so that version mismatches between partners can be detected. The import reads that version from the file it is processing.

If there is no data file to read — or the file is empty — the import cannot see a version, and it reports the generic old-version warning. It also reports zero objects, for the same reason.

Both messages are the defaults for "no data file was found". They are not evidence of a version problem. If both sides are genuinely on 8.6 or later, stop investigating versions and start investigating why the file did not arrive.

Where to look, in order

The fault is on the export and delivery side, not the import side.

1. Did the export policy run at all? Check its status and, more usefully, its log summary — the analysed and exported object counts tell you whether a file was produced.
2. Was a data file created? A run that reports errors may complete without producing a file, particularly if the export safety limits held it back on purpose.
3. Was it sent? Where the transfer method is mail, check the exporting side's Sent Items or the GALsyncArchive folder for the outgoing message carrying the data file. An export that produced a file but failed to send it is a common shape of this problem.
4. Did it arrive? Search the importing side's GALsync mailbox — including spam and quarantine — for a message with GALsync in the subject. Data files travel as attachments, and attachment filtering is a recurring cause.
5. Can it be decrypted? If the policies use encryption, confirm the symmetric key matches on both sides, on the policy's Encryption tab. A key mismatch prevents the file from being read.
6. Is the export scope still producing objects? On the export policy's Directory tab, check the selected group or OU still contains objects, and review any filters — including whether Synchronize objects hidden from address lists matters for your set.

Running the export manually and watching whether a file is produced and sent usually settles which half of this list applies.

Why a manual rerun "fixes" it

Re-running the export typically produces and sends a fresh file, and the next import then succeeds. That resolves the incident, and it is the right immediate action.

It does not establish a root cause. Where this recurs — a failure, a manual rerun, a clean run, then the same failure weeks later — the underlying delivery problem is still there. Treat a rerun as a workaround and keep the case open until you know why the file did not arrive the first time.

Worth capturing while it is happening, because it is hard to reconstruct afterwards:

• Whether the export log shows the file was created, and whether it shows the send succeeding.
• Whether the message appears in Sent Items or GALsyncArchive on the export side.
• Whether anything appears in the import mailbox, quarantine or spam at the expected time.
• The timestamps of all of the above, so mail flow can be traced.

Guard against the consequence

This failure mode is benign in one specific way: an import with no data file imports nothing. It does not delete contacts, because it has nothing to reconcile against.

The dangerous neighbour is an import that receives a partial file — that does reconcile, and removes everything not present. Setting Minimum objects to transfer data file and Maximum errors to transfer data file on the export policy prevents a short file being sent at all. See How to Prevent GALsync Contact Deletion During Export Errors.

Clear out stale data files

One related trap. If old data files accumulate in the GALsync mailbox, an import can pick up an outdated one — which does reconcile, against stale content.

Keep only the most recent data file per import policy in the mailbox, particularly after a server move or a period when imports were not running.

When the version message is real

Version mismatch between partners is a genuine condition, and the warning is doing its job when a file is present. All partners must run the same version; environments below 8.2.0 cannot import current data files at all. If a file is arriving and the warning appears, confirm the exporting partner's actual version rather than assuming. See Planning a GALsync or contactSync Upgrade.

References

• GALsync 8.6.0 changelog — the data file header expanded with the program version; environments below 8.2.0 cannot import current data files.
• GALsync 8.7 Manual p.167 — export safety limits.
• The current GALsync manual and version history are published by NETsec at netsec.de.