Licence Keys in Practice
What actually resets a licence, the errors a bad key produces, and how to handle HA pairs, restores, and trials without downtime.
Licensing Infohub covers the model — instance binding and the two expiry dates. This article covers the operational half: the events that invalidate a working key, the messages each failure produces, and the situations that generate most licensing traffic.
What the key is actually bound to#
An Infohub licence is validated against the database's identity, not the machine's. Two values matter:
- The database's
group_database_idfrom SQL Server's ownsys.databasescatalogue - The
InstanceIDsystem property stored inside the Infohub database
The first is assigned by SQL Server, and that is the fact everything below follows from: anything that gives the database a new group_database_id invalidates the licence, even though nothing in Infohub changed.
Operations that reset a licence#
| Operation | Resets? | Why |
|---|---|---|
| Restoring the database — same server or another | Yes | The restore creates a new database identity |
| Adding/removing the database from an Availability Group | Yes | group_database_id is AG-related by definition; AG membership changes it |
| HA failover within an established AG | Usually no | Identity is shared across replicas — but AG reconfiguration does reset it |
| Moving to a new SQL Server | Yes | New identity |
| Renaming the database | No | Identity is the GUID, not the name |
| Upgrading Infohub | No | Same database |
| Upgrading Windows or SQL in place | No | Same database |
| Detach/attach | No — but test in your environment | The GUID normally survives |
Plan the key request into the change, not after it. Every restore, AG change, or server move should include "request a new licence key" as a step, with the new details captured from Flow Config → Help → License → Copy Details immediately after the move. Sites that fold this into the change window never notice; sites that don't discover it when the engines refuse to start.
Recognising each failure#
| Symptom | Meaning |
|---|---|
Components deploy but never run; licence refusal in the Flow event log |
No valid licence for this database identity — the usual post-restore state |
| "Licence tampering" in the logs | The licence's recorded identity or counts no longer match the database — same family as above, and also raised when the measure/event count exceeds the licensed count |
IDX10400: Unable to decode when applying a key |
The key string itself is corrupt — usually mangled in transit (a character case-flipped by an email system). Request a re-issue and paste, never retype |
| "New Key Request" after an upgrade | Older-format key on a newer Infohub — supply the current-format key |
| Long key rejected by the UI | Pre-7.x Infohub cannot accept the current long key format — see Upgrading from Flow 6.x |
| Backfill prompts a licence notification | An expired maintenance date does not stop backfill; an expired licence stops processing. Check which date lapsed |
Key formats#
Current keys are long JWT-style strings (they begin eyJ...). They encode the part, creation and expiry dates, and the measure/event/MCP counts — which is why a key is not transferable between differently-sized sites. Older short-format keys (XXXX-XXXX-...) belong to older Infohub versions.
Apply a key in Flow Config → Help → License, or from the CLI with --license. Exit code 10 means the apply failed — read the message rather than retrying.
Trials, bridges, and moves#
Trial and temporary keys carry a short licence expiry. Everything runs normally until the date, then processing stops — nothing degrades gradually. Track the date.
Bridge keys cover a renewal that is stuck in purchasing. Ask before the expiry, not after: an expired production licence stops calculation immediately.
Moving an instance to a new server: install Infohub, restore the database, fix the Platform host name, then request a key against the new details. There is no way to pre-generate the key, because the new group_database_id does not exist until the restore has happened. Budget a gap, or keep the old server running until the key arrives.
Reallocating measures between sites (group licences): each affected site gets a re-issued key with its new counts. Apply them in the order support specifies — shrinking one site before growing another.
Counts are enforced#
The licence caps measures, events, tags, and MCP connections. Exceeding a cap surfaces as the tampering message rather than a friendly warning. Before a large instantiation or template rollout, compare the model's counts against the licence — --list-measures piped to a count is a one-liner, and it is much cheaper than discovering the ceiling mid-rollout.
The details support needs#
Every licence request resolves fastest with the output of Help → License → Copy Details, which includes the key, part, GUID, instance, expiries, and counts. A screenshot of the dialog loses the key string's exact characters; the copy button exists precisely because retyped keys arrive corrupt.