Collecting GALsync and contactSync Logs for Support

Purpose

Almost every support case starts by asking for the same two files. Sending them correctly the first time is the difference between a diagnosis and a week of round trips. This article covers what to send, how to check it before sending, and what to say alongside it.

The two exports

Both are produced from the Action menu and both arrive as zip files.

Action → Export Configuration — the policies and environment configuration.
Action → Export Status — the log files.

Send both. The configuration explains what the product was told to do; the logs explain what happened. Either alone usually prompts a request for the other.

Send from both servers

Where a GALsync synchronization involves an exporting server and an importing server, collect both exports from both machines. A synchronization failure is a conversation between two files, and one side rarely explains it.

This applies even when you are confident the problem is on one side. A contact deleted at the target is explained by what the export produced, not by what the import did with it.

contactSync operates within a single environment, so one set is sufficient there.

Check the logs before you send them

This is the step that saves the most time, and it takes under a minute.

Open the Export Status zip and check the date of the newest log file. If it predates the failing run, the archive will be analysed against evidence that does not contain the problem.

This happens more often than you would expect — because a run that fails early may write little or nothing, because a change was made after the last run, or because the archive captured an older set. Cases have lost several rounds to logs that did not reflect the change being tested.

If the newest log predates your most recent attempt, either run the policy again to generate a current log, or say so explicitly when you send the archive.

Individual runs

For a specific failing run rather than everything, the Status tab lets you right-click a run and choose Export log file, or Export all log files.

Useful where a full status export would be very large — a long-running import on a big contact set can produce a substantial log.

Where the files live

If you need to reach them directly rather than through the console:

%ProgramData%\NETsec GmbH & Co. KG\GALsync

%ProgramData% is hidden by default in Windows Explorer — enable Show hidden files, folders, and drives, or paste the path directly. This folder holds the policies, encryption keys and log files, and it persists if the software is uninstalled.

contactSync uses the equivalent folder under the same parent.

Reading the logs yourself

The NETsec LogViewer is the tool for these logs. On a large or long-running policy the log is far too big to read chronologically, and searching by error code is much faster than scrolling.

Two things worth checking before you raise a case at all, because they often answer the question:

The summary counts. Analyzed: 0, Added: 0, Errors: 4 means the run never reached any objects — typically a connection or licence problem, not a data problem. A completion status is not success.
The object count against the previous run. A sudden drop precedes every mass deletion and is the earliest warning available.

What to say when you send them

Include these, because each one removes a round trip:

The exact product version — and if this followed an upgrade, the version you came from. The version span is the single most useful fact in a post-upgrade failure and the one most often missing.
Exact error codes and messages, copied as text rather than as a screenshot. Screenshots cannot be searched, and error text pasted into a case is what lets someone match it against a known issue.
When it last worked, and what changed around then — an upgrade, a certificate renewal, a licence change, a server move, a Microsoft-side change.
Whether it fails manually, on schedule, or both. This one distinction separates an entire class of causes, because scheduled policies run as the service account.
How many objects are involved, and whether the failure affects all of them or a subset. If a subset, what those objects have in common.
Whether synchronization is currently down, so it can be prioritised accordingly.

Before you send: two quick self-checks

Both take a minute and both resolve a meaningful share of cases:

Is the licence current and activated for the installed version? Help → About. A version upgrade requires a new key, and an unactivated licence cancels policies while everything else looks correct.
Does a manual query return what the product says is missing? If a manual Exchange Online PowerShell query returns full attributes while the policy reports them empty, the fault is in the context the policy runs in — module version, service account, application scope — not in your tenant data. Say so; it localises the problem immediately.

A note on sending files securely

Log and configuration exports contain your directory structure, policy configuration and object names. Treat them as you would any other export of directory data, and use the secure transfer link support provides rather than email where the files are large or the content is sensitive.

References

GALsync 8.7 Manual p.74 — program and data folder locations; the note that %ProgramData% is hidden by default.
The current manuals and the NETsec LogViewer are published by NETsec at netsec.de.

Articles in this section