Purpose
Licence problems stop synchronization, and they are easy to hit at the two moments when you least want an outage: at renewal and immediately after a version upgrade. This article covers how licences work, how to apply one, and the two traps that account for most licence-related tickets.
Applying a licence
The licence is a .lic file, applied from within the product:
Help → About → Add License
After applying it, confirm the licence is shown as active and that the object and organisation counts match what you expect — not merely that the file was accepted.
What a licence permits
A GALsync licence is sized on two dimensions, both of which matter:
- Mail-enabled objects — the number of objects that may be synchronized.
- Organisations — the number of environments participating in the synchronization scheme.
Tiers combine the two, for example up to 550 objects across 2 organisations, 1,500 across 4, or 5,000 across 4. Adding a partner environment can therefore require a licence change even when your object count has not moved.
Perpetual licences carry a separate Support and Version Assurance (SVA) period with its own date range. Subscriptions run for a term. Both are worth diarising, because in practice the first sign of expiry is usually a failure rather than a reminder.
Trap 1: a major version upgrade needs a new key
A licence issued for an earlier major version is not accepted by a later one. An 8.4 licence applied to an 8.6.3 installation is rejected, and every import and export policy fails until a current key is applied.
This is worth being direct about because the opposite is sometimes assumed. If you are planning an upgrade, request the licence for the target version before you upgrade, not after. Otherwise the upgrade completes, policies stop, and you wait on a licence while synchronization is down.
Add it to the upgrade checklist alongside the platform prerequisites. See Planning a GALsync or contactSync Upgrade.
Trap 2: the licence file gets corrupted in transit
Licence files arrive by email, and mail security or antivirus scanning of attachments can corrupt a .lic file. The symptom is an error when the key is applied, with a file that tests as valid at the sender's end.
Two workarounds:
-
Change the extension for transit. The sender renames
.licto.txt; you rename it back to.licafter it arrives. - Use a secure file transfer link rather than an email attachment.
If a key fails to apply, try this before assuming the key itself is wrong — it is the more common explanation.
What happens when a licence lapses
Plan on the basis that an expired or mismatched licence stops synchronization. Policies fail, and in a renewal gap that means the address lists on both sides stop being maintained.
Practical consequences:
- Treat the expiry date as an operational deadline, not an administrative one.
- Start a renewal well ahead of expiry — licence issuance takes time, and keys are issued by NETsec in Germany, so a request raised late in the working day may not be actioned until the following day.
- If you are already down, say so explicitly when you raise the request, so it is handled as an outage rather than as routine fulfilment.
When policies fail and you suspect the licence
- Check the licence status at Help → About. Confirm it is present, activated, current for the installed version, and covers your object and organisation counts.
- Confirm activation, not just installation. An unactivated licence cancels policies while everything else looks correctly configured.
- Check the version. If the product was upgraded recently, a version mismatch is the likely cause.
- Read the summary counts in the log rather than the completion status. A policy that fails on licensing still reports a status.
If the licence checks out, the cause is elsewhere — see GALsync Policies Cancel or Fail: Working Through the Causes in Order, where licence activation is the first check and the others follow in order.
Requesting a licence or a renewal
Include, so it can be actioned without a round trip:
- The exact product version installed, or the version you are upgrading to.
- The object count and number of organisations required.
- Whether synchronization is currently down.
- Any change to the scheme — a new partner environment, a server move, an increase in object count.
The version is the field most often omitted and the one most likely to cause a wrong key to be issued.
Comments
0 comments
Please sign in to leave a comment.