Installation Binding

An Installation ID ties a licence to one specific appliance. Once a licence is bound, it will not unlock features on any other machine.

Installation binding is how the vendor stops a licence from being copied off one customer’s appliance and reused elsewhere. It is also the mechanism that decides which appliance “owns” a particular support contract. Most customers never have to think about it — the appliance generates its ID on first boot, the vendor issues a licence against that ID, and everything just works.

This chapter explains what the Installation ID is, how it is derived, what binding protects you from, and what to do when something changes.

What the Installation ID Is

A unique, stable identifier generated the first time the appliance starts. Once generated it persists for the life of the installation.

The ID is shown at the top of the License page (chapter 37). It looks like a UUID — a long string of hex characters and dashes — and is unique to this appliance. The vendor uses it as the binding target when they issue a machine-bound licence to you.

Two important properties:

Stable. The ID does not change as the appliance runs. Rebooting, upgrading the software, applying a new licence, adding users — none of that affects it.
Persistent. The ID lives in the appliance’s configuration store. It survives daemon restarts and software upgrades. It only disappears if the configuration store itself is wiped (factory reset, fresh install).

When the ID Is Generated

The very first time the appliance starts, it generates a fresh Installation ID and writes it to the configuration store. Subsequent starts load the existing ID.

You do not trigger generation. It happens during the first-boot initialisation, before the GUI is even reachable. By the time you log in for the first time, the ID is already present and shown on the License page.

This means:

Installing the same software image on two machines produces two different IDs.
Cloning an appliance VM after first boot keeps the original ID on the clone — which is exactly the case binding is meant to detect (see Cloning Detection below).
Reinstalling from scratch on the same hardware produces a new ID.

How the ID Is Derived

The appliance generates the Installation ID as a random UUID on first boot and stores it in its configuration database.

The ID is not a hash of hardware fingerprints. It is a freshly generated random value that the appliance assigns to itself. This is intentional — it means the ID is stable across hardware changes you have control over (replacing a failed disk, adding RAM, upgrading the CPU) without requiring a re-binding ritual every time.

What this trades off:

You gain: stability against routine hardware maintenance.
You lose: the ability to derive the ID from the hardware alone — you must have the value the appliance stored.

The configuration store on disk is therefore the authoritative source for the ID. If you back up the appliance, make sure the configuration store is in the backup. Restoring an old backup will restore the old Installation ID along with it.

What Binding Prevents

Binding makes a licence single-use. Copying the licence file to another appliance does not unlock features there.

A bound licence carries the Installation ID inside its signed payload. When the appliance verifies the licence:

ASCII fallback

            +---------------+        +---------------+
            |    Licence    |        |   Appliance   |
            |               |        |               |
            |  bound to:    | -----> | check matches | -----> [unlock]
            | <inst-id-A>   |        | <inst-id-A>   |
            +---------------+        +---------------+

            +---------------+        +---------------+
            |    Licence    |        |   Appliance   |
            |               |        |               |
            |  bound to:    | -----> | check matches | -----> [refuse]
            | <inst-id-A>   |        | <inst-id-B>   |
            +---------------+        +---------------+

If the IDs do not match, the appliance refuses to honour the licence. The licence is still cryptographically valid — the signature is good — but the binding payload says it belongs to a different machine, so the verifier rejects it.

What this protects against: a copied licence file unlocking a second appliance, a malicious tenant sharing your licence with another tenant, or a stale licence being lifted from a backup and used to run a “free” instance.

What this does not protect against: somebody who has full filesystem access to your appliance. Binding is a licensing control, not a security control against root.

Unbound Licences

Not every licence is bound. The vendor can issue a licence with binding mode set to any, which works on any Installation ID. These are typically used for evaluation, demos, or development environments. Production licences are almost always bound.

You can tell which mode you have on the License page — the Binding Mode field in the licence details reads either bound or any.

Cloning Detection

If two appliances ever run with the same Installation ID, the vendor’s support server can detect it. This is the practical defence against VM cloning.

The appliance’s Installation ID is sent to the vendor over the Support Backchannel (chapter 34) every time it connects to the support server. If two appliances connect with the same ID, the vendor knows that one of them is a clone. The same logic catches “I restored a backup onto a new VM and kept it running alongside the original” — both VMs report the same ID.

What you can do to avoid tripping this:

Decommission the old appliance before bringing up a replacement from a backup.
Treat backups as cold spares. Restoring a backup is fine — running the restored VM in parallel with the original is not.
Tell the vendor when you are doing a planned migration. They can issue a transitional licence that covers the cutover.

What Happens if Hardware Changes

Routine hardware changes do not affect the Installation ID, because the ID is stored in the configuration database, not derived from hardware.

Some changes are entirely transparent:

Change	Effect on Installation ID
Reboot	None
Software upgrade	None
Disk replacement (keeping the configuration store intact)	None
Adding RAM, CPU, NICs	None
Migrating the VM to a new hypervisor (configuration store comes with it)	None
Restoring the configuration store from backup	None — old ID is restored

Some changes do reset the ID, because the configuration store is gone:

Change	Effect on Installation ID
Factory reset	New ID generated on next boot
Fresh install on the same hardware	New ID
Loss of the appliance with no backup, rebuild from scratch	New ID

A new ID means your existing bound licence will no longer match. The new appliance has a fresh identity and needs a fresh licence (or a rebinding — see below).

Recovery Procedure

You have lost the original Installation ID. The appliance is unlicensed. Here is how to get back to a valid state.

The flow is the same whether the trigger is a factory reset, a disaster recovery, a planned migration to a new VM, or a hardware refresh.

Step 1 — Find the new Installation ID

Step 2 — Contact the vendor

Reach out to your vendor support contact. Provide:

The customer name and licence ID from the original licence.
The new Installation ID.
The reason for the change (factory reset / DR / migration / hardware refresh).

The vendor verifies you are the rightful owner of the original licence and decides on the path forward. Typically they:

Revoke the old binding on their side so any leftover copies stop working.
Issue a new licence bound to the new Installation ID, with the same tier, expiry, and entitlements as the old one.

Step 3 — Apply the new licence

Paste or upload the new licence on the License page. The current licence panel refreshes with the new details. Features unlock immediately — no restart needed.

Step 4 — Decommission the old appliance

If the old appliance is still reachable, take it offline. If you cannot reach it (it is gone), the vendor’s revocation already handles the binding side — the old licence will refuse to verify if anyone tries to bring it back up.

Plan migrations. A planned rebinding is a 10-minute exchange with the vendor. A panic rebinding on a Friday evening because of a crash is much less fun. Open a ticket before you make the move.

Binding Errors at Upload Time

When you upload a licence whose binding payload does not match this appliance’s Installation ID, the upload fails with a dedicated binding-error panel.

The panel includes:

A clear “License Binding Error” heading.
The specific error returned by the verifier.
A prompt to contact the vendor with this appliance’s Installation ID.

The previously installed licence (if any) is not affected. Your appliance is not pushed into an unlicensed state by an attempted upload of a wrong licence — only a successful upload changes the licence store.

If you see a binding error you did not expect:

Check that you are uploading the right licence — the licence file you received from the vendor for this appliance, not a different one.
Compare the Installation ID shown on this appliance to the one the vendor used to issue the licence. The vendor’s licence-issue email or portal usually shows the ID the licence is bound to.
If the IDs do not match, contact the vendor — either they bound it to the wrong ID, or you have switched appliances and need to follow the recovery procedure above.

When the System Clock Lies

The appliance tracks the timestamp of the last licence check. If the system clock jumps backward by more than an hour, the appliance refuses to validate the licence.

This is a tamper-detection safeguard. Without it, an attacker who could move the clock backward could keep an expired licence “valid” indefinitely by rewinding the date.

What you see when this triggers:

The licence panel shows “System clock tampering detected” instead of the usual valid/expired pill.
Licensed features lock as if the licence had expired.

What to do:

Verify the system clock is correct — use date from the Terminal (chapter 33) or check NTP synchronisation.
Fix the clock. If NTP is broken, repair it; if a user changed the date manually, set it back to the real time.
The next licence check after the clock is correct will succeed and re-enable features.

Forward clock jumps are fine — only backward jumps of more than an hour trigger the tamper detection.

License Management (chapter 37) — uploading, viewing, and renewing the licence that this Installation ID binds.
Support Backchannel (chapter 34) — uses the same Installation ID to authenticate to the vendor’s support server, and is how cloning is detected.
Architecture (chapter 1) — for where the appliance sits in the wider picture.