Licensing

DPLens is licensed with a signed key that works offline. The agent checks the key against a publisher key built into the program.

It never contacts a licensing service and sends no telemetry. An air-gapped machine is a normal deployment.

A key is a single line of text beginning DPL1. It is a signed token, not a secret: it can sit on an installer command line, in a deployment bundle, or be pasted into the console. It cannot be altered without invalidating it, and — unless it is a trial or an unlocked key — it cannot be used on a system it was not issued for.

What a key covers

A receiver seat is counted per configured, enabled receiver source — never per device sending to it. One syslog receiver taking events from 500 firewalls uses one seat. A paused receiver uses none.

The Sources page shows each receiver's seat, and Settings and audit → Licence shows seats used against seats available.

What a key is locked to

Every key is one of four kinds:

• A machine key is locked to one system. A machine key is locked to this system using multiple unique hardware and software identifiers, which protects against licence abuse. A key stays valid through routine hardware maintenance; if the system changes substantially, request a new key. The Licence page shows how many of the system's identifiers a key matches.
• A domain key is locked to one or more Active Directory domains — every machine joined to a named domain, or to a child of it.
• A trial key is valid on any system for up to 120 days from the day it is issued. The usual expiry warnings apply.
• An unlocked key is valid on any system for the contracted term, at most five years. It is issued by arrangement for large or complex estates, and the agent records its presence in the audit log at every start.

A machine or domain key does not verify anywhere else.

See Golden images and VDI clones.

Applying a key

Two ways in, one place it is stored.

At install

msiexec /i dplens.msi /qn LICENCE_KEY=<the key>

or

msiexec /i dplens.msi /qn LICENCE_FILE=C:\deploy\dplens.lic

The key is verified against the machine before the service starts. A key for a different machine, a different domain, an expired key or an altered one fails the installation and says which, rather than leaving you with an agent that quietly collects nothing.

Installing without a key succeeds; the agent starts unlicensed.

Deployment bundles carry the key for you — see The deployment bundle.

Licence keys in a deployment MSI

A deployment MSI carries a list of keys — a domain key for the joined machines and machine keys for particular hosts, say — and the rule for the list is different from the rule for a single key on the command line, because one package installs on many machines:

• At install, each machine keeps the first listed key that verifies on it and discards the rest; they are never written to that machine. If none verifies, the installation still succeeds and the agent starts held — so the machine is installed, configured and visible, and the Licence page says why it is not collecting. Each kept and each discarded key is recorded in the audit log with the reason.
• At an update — a newer package over an installed agent, or a push of a new bundle — a working licence is never removed. A listed key that verifies on the machine replaces the current one and the change is recorded; keys that do not verify are left aside and, for a push, listed in the host's result. A machine whose current key no longer verifies takes the first listed key that does.

A single key passed with LICENCE_KEY or LICENCE_FILE keeps the strict rule above: a key that does not verify fails the installation.

From the console

Settings and audit → Licence → Apply a licence key. Paste the key and save.

It is verified against this machine immediately. If it verifies, collection starts at once — you do not need to restart anything. If it does not, nothing changes and the page tells you why.

Either way the change is recorded in the audit log, under your name. The key itself is never written to the audit log.

Where it is stored

C:\ProgramData\DPLens\config\licence.key

One file. The installer writes it; the console rewrites it. Back it up with agent.yaml.

A licence key in agent.yaml is not read. The configuration is a document you edit and copy between machines; the licence is a fact about one machine, and mixing them would mean a configuration that silently stops working when copied.

What "unlicensed" means

Without a valid key, DPLens holds its data plane: nothing is collected and nothing is delivered.

Everything else stays up — the console, the audit log, the secret store — so you can enter a key. You can configure the whole agent while it is held, and the moment a valid key arrives, what you configured starts running.

The Overview shows a banner, and Settings and audit → Licence gives the reason.

The same hold applies when:

• The key stops matching the system — it left its domain, the state came from a cloned image, or a machine key's system changed substantially. There is no grace for this; it is taken at the next start or configuration change. A machine key tolerates routine maintenance; the Licence page shows how many of the system's identifiers still match, so you can request a new key before the next change.
• You have configured more receivers than the key allows. The console refuses to apply such a configuration and names the entitlement. A configuration that arrives that way — an install with a smaller key — holds instead.

Expiry

Every key has an expiry date, inclusive, in UTC. What happens is fixed and visible in advance, and every step is recorded in the audit log.

Events already collected stay in the destination caches when it stops, subject to the cache sizes you set, and delivery resumes the moment a valid key is applied.

The clock

The ladder is evaluated against the latest date the agent has ever seen, not the current clock. Setting the clock back does not extend grace; it is counted and recorded.

Seeing where you stand

Settings and audit → Licence shows the state, the kind of key, the customer the key was issued to, the licence id, the expiry with days remaining, the agent entitlement, receiver seats used against available, what the key is locked to, and this system's own identity line — the line you paste into a request for a machine key.

It never shows the key itself.

To print the identity line without the console:

"C:\Program Files\DPLens\dplens.exe" --host-facts

It prints one line beginning DPHF1. The line identifies the system without revealing anything about it; it is safe to send by email.

To check a key before using it:

"C:\Program Files\DPLens\dplens.exe" --verify-licence C:\deploy\dplens.lic

It prints one line saying whether the key verifies against this machine, and why not if it does not.

Getting a key

To request one, have ready:

• The kind of key — machine, domain, trial or unlocked.
• What to lock it to — for a machine key, the system's identity line from the Licence page or dplens.exe --host-facts; for a domain key, the Active Directory DNS domain or domains to license.
• How many receiver seats you need, for syslog and for NetFlow.
• The term — up to 120 days for a trial, up to five years for an unlocked key.

Email contactus@dplens.com.

The publisher key

Every licence key is signed by the DPLens publisher key, whose public half is built into the program. The private half is held by the publisher alone: it is not in any shipped build, and no installed copy of DPLens can issue keys.

The Licence page shows which publisher key signed yours. If a publisher key were ever compromised, it would be retired in a point release and keys re-issued — so a different key identifier appearing on your Licence page is expected only after such an announcement.