Skills

Polarion Salt Licensing

Skill polarion-salt-licensing. Make Polarion 2606 obtain a SALT licence, and diagnose it when it will not. Covers the three configuration surfaces and which one actually wins, the rule that SALT validates the COMBINATION of licence sources so one bad entry invalidates a good one, the vendor-daemon mismatch (features issued to ugslmd while Polarion's client wants saltd) that produces two completely different error messages from one cause, the consolidated-vendor-daemon reading that makes "no features are served" look true when it is false, and the instrument ladder that answers the question in one call instead of six. Use for any Polarion licensing failure, "License cannot be obtained", "missing server_id feature", "Invalid (inconsistent) license key", a SALT server that appears to serve nothing, or before asking Siemens to reissue a licence.

Provenance is marked throughout. EXERCISED came back from a real call on this estate (Polarion 2606 at D:\Polarion on MARTINI-GAMING, Siemens License Server at 29000@localhost, 2026-08-19). DERIVED was read out of the shipped 2606 documentation and has not been run.

Recorded after a session that spent roughly three hours and four hypotheses on a licence that was sitting on the server, available, the entire time. Three of the four hypotheses were wrong, and two of them were more quotable than the truth. The fix was a licence reissue, and the evidence that justified asking for it took four commands.

1. The architecture, because the names mislead

Thing	What it is
`lmgrd`	FlexNet licence manager, listens on 29000
`saltd`	the SALT vendor daemon, listens on 29001, started by `lmgrd`
`ugslmd`	the classic Siemens PLM vendor daemon (NX, Teamcenter, Amesim, Simcenter)
SALT	Siemens Automated Licensing Technology, what Polarion 2606 licenses through

⚠ saltd here is a CVD, a Consolidated Vendor Daemon. Its own log says so:

Is vendor daemon a CVD: Yes
Serving features for the following vendor names:
 saltd  mgcld  ugslmd  cdlmd  RCTECH  ccslmd

One process serves features belonging to several vendor names. This single fact invalidates the most obvious diagnostic you will reach for. See section 5.

Polarion licence features are named pln_*: pln_alm_n (ALM named), pln_alm_c (ALM concurrent), pln_qa_n, pln_qa_c, plus pln_copilot*, pln_cyber* and others depending on entitlement. There is also a server_id feature that SALT requires and that is easy to overlook.

2. The three configuration surfaces, and which wins

EXERCISED. All three matter and they interact.

1. SALT_LICENSE_SERVER            machine environment variable   <- WINS
2. com.siemens.polarion.license.salt.server=      polarion.properties
3. com.siemens.polarion.license.salt.enabled=false polarion.properties  <- kill switch

The documented value forms are port@host for a served licence and a full path to a licence file for node-lock. Default port is 29000.
The environment variable takes precedence over the property. The guide says so ("General SALT Server configuration notes", topic ksq1710920059958) and it is EXERCISED: with the property set to 29000@localhost and the env var set to something else, Polarion's own log printed the env var's value. So setting only the property while a machine env var exists is a silent no-op.
com.siemens.polarion.license.salt.enabled=false ("Disable SALT licensing", topic jea1725004198955) turns SALT off entirely and drops Polarion onto its trial. While this line is present, everything else in this skill does nothing. Check for it first.
Both properties are system level: they live in D:\Polarion\polarion\configuration\polarion.properties and need a Polarion restart. They are not settable from Administration.

⚠ Do not leave the env var and the property disagreeing. They are two definitions of one value and they drift. Set both to the same thing, or set only the env var.

⚠ The services.exe environment cache is NOT a problem here. It is the obvious suspect (Windows caches the service environment block at boot, so a Machine env var changed later classically does not reach a service). EXERCISED: it does reach it. Polarion's licensing log printed the newly written value after nothing more than Restart-Service Polarion. Do not spend a reboot on this theory without checking the log first.

3. ⚠⚠ SALT validates the COMBINATION of sources, not the first usable one

This is the finding worth the whole skill, and it is in no documentation.

SALT_LICENSE_SERVER accepts a ;-separated list of servers and file paths. A reasonable person assumes SALT tries them in order and uses the first that works. It does not. It validates them as a set, and one invalid entry rejects the entire configuration.

EXERCISED, three runs:

license.txt;29000@localhost   -> "License server has a bad configuration due to a missing server_id feature"
29000@localhost;license.txt   -> identical error   (reordering changes nothing)
29000@localhost               -> different error, progress

The license.txt in that list was an unrelated node-locked file holding one Mentor feature and zero server_id lines. The server had server_id and 400 free Polarion seats the whole time.

⇒ Never diagnose licensing with more than one source configured. Reduce to a single entry, prove it, and only then compose. A mixed configuration is precisely how a good source is hidden by a bad one while the error names something else entirely.

4. ⚠⚠ The vendor-daemon mismatch: one cause, two unrecognisably different errors

EXERCISED, and it cost most of the session.

The entitlement had been generated against vendor daemon ugslmd. Polarion's SALT client works against saltd. That single mismatch produced two errors that look like separate problems:

Route	Error	Why
Served, `29000@localhost`	`License server has a bad configuration due to a missing server_id feature`	SALT asks its own vendor daemon for `server_id`; nothing was issued to `saltd`
Node-locked file	`Invalid (inconsistent) license key`	FlexNet signature failure: `ugslmd`-signed data verified against the `saltd` key

Neither message says "wrong vendor daemon". The first names a feature that demonstrably exists on the server. The second looks like a corrupt file, so you will go and check for a BOM, CRLF, and trailing whitespace (all worth checking, all clean).

The fix is a licence reissue, not configuration. Ask Siemens for the entitlement issued for SALT, vendor daemon saltd, including server_id. After the reissue a new ActiveLicenses\saltd.lic appeared and INCREMENT counts by vendor went from 4826 ugslmd / 0 saltd to 4840 ugslmd / 4499 saltd. Polarion licensed immediately.

Tell-tale that you are in this case: lmdiag says the feature can be checked out, and Polarion still says it is missing. A FlexNet client can see it; the SALT client cannot.

5. ⚠⚠ The reading that makes a true entitlement look absent

The obvious diagnostic is to count which vendor daemon each licence line is issued to:

grep -rhiE "^\s*(INCREMENT|FEATURE)\s" ActiveLicenses/*.lic | awk '{print $3}' | sort | uniq -c

and lmstat -a groups its output by vendor name, so an empty section reads as "this daemon serves nothing":

saltd: UP v11.19.8
Feature usage info:
                          <- empty
ugslmd: UP v11.19.8
Feature usage info:
Users of AMEBOEING: ...   <- everything is here

⚠ Both readings are worthless on their own, because saltd is a CVD. A CVD legitimately serves features issued to other vendor names, so a feature carrying ugslmd in field 3 may still be served by saltd, and an empty saltd section does not mean it serves nothing.

This reading produced a confident, quotable, wrong conclusion ("there is no Polarion entitlement, the licences you installed do not include Polarion") that would have led to disabling SALT while 400 seats sat available. It was caught only by a human saying that is not how flexlm works.

⇒ The vendor field is a hypothesis generator, never a verdict. It turned out to point at the real cause, but only after lmdiag and the two error messages corroborated it. Do not act on it alone.

6. The instrument ladder

Run these in order. Each answers a different question, and each has a failure mode.

a. Is the feature there at all, and is it free? Use the Siemens lmutil, not another vendor's copy:

"C:/Program Files/Siemens/License Server/lmutil.exe" lmstat -a -c 29000@localhost | grep -iE "Users of pln_|Users of server_id"

(Total of N licenses issued; Total of M in use). EXERCISED: a Mentor Graphics lmutil at C:\MentorGraphics\Install\bin\LMUTIL.EXE gave a less complete picture of the same server.

b. Can it actually be checked out? This is the strongest single test, because it performs a real checkout attempt rather than reporting inventory, and it prints the vendor:

lmutil lmdiag -c 29000@localhost server_id
lmutil lmdiag -c 29000@localhost pln_alm_n

Look for This license can be checked out and the vendor: field. ⚠ lmdiag searches by feature name and will succeed against a feature the SALT client cannot use. lmdiag succeeding does not mean Polarion will work. It narrows the fault to the client side, which is exactly what you want.

c. Did Polarion ever ask? C:\ProgramData\Siemens\License Server\saltd.log:

grep -nE 'OUT: "(pln_|server_id)' saltd.log | tail

⚠ saltd.log records successful checkouts. It does not record failed ones. A frozen log means "no successful checkout", not "no request arrived". Do not read its silence as proof the client never connected. Use netstat for that: connections to 29001 in TIME_WAIT from this host show the client is talking to saltd even when the log is silent. ⚠ And for a node-locked licence the client reads the file directly and never contacts the daemon, so silence there is correct.

d. What does Polarion itself say? This is the artefact that ends the argument:

D:\Polarion\data\logs\main\log4j-licensing-<timestamp>.log

Two lines carry everything:

INFO  PolarionLicensing - Trying to connect to SALT Server: <the value actually in force>
ERROR PolarionLicensing - <the real error>

Line 1 tells you which of the three configuration surfaces won, which kills the whole class of "is it picking up my change" questions in one read.

⚠ Do not measure these logs by file size. EXERCISED twice: a directory listing reported log4j-startup-*.log as 0 bytes when it held 13,616, and [System.IO.File]::ReadAllText returned ~210 characters of a file whose line 1526 Select-String read fine. The files are open and being written. Select-String was the only instrument that gave true answers.

e. Raising the client's own logging buys less than you expect. Adding a debug logger for com.siemens.polarion.salt (in D:\Polarion\polarion\plugins\com.polarion.core.util_*\log4j2.xml, pointed at the existing LICENSING appender) yields only:

DEBUG SaltService - Analytics Interface already configured, skipping.
WARN  SaltService - SaltException: <the same error>

The Java layer is a thin wrapper; the request is made by a native library that does not log through log4j. Worth knowing so you do not spend a restart on it.

7. Node-locked versus served

DERIVED from "Configure Polarion" (topic vdb1709734615662), shapes EXERCISED.

Served: the file has a SERVER line. Point SALT_LICENSE_SERVER at port@host. Checkouts appear in saltd.log as OUT: "pln_alm_n" user@HOST.
Node-locked: no SERVER line, uncounted INCREMENTs, a HOSTID=. Point SALT_LICENSE_SERVER at the full file path. No daemon involvement, no saltd.log entries.

Placement for a node-locked file: under C:\ProgramData (machine-wide, and the Polarion service runs as LocalSystem), in its own filename. ⚠ Do not append to an existing NodelockedLicenseFiles\license.txt: that file is rewritten by a Siemens licence import tool, which leaves an importReport.txt beside it. Check the ACL grants NT AUTHORITY\SYSTEM read access; a node-locked file the service cannot read fails in a way that reads like a bad licence.

Before betting a restart on a node-locked file, check it carries server_id:

grep -c "server_id" polarion.lic     # 0 means you already know the outcome

The licence header states its own intent and is worth reading:

# Server(s):       MARTINI-GAMING, node locked
# Products:        Polarion

⚠ A header saying Products: Polarion with a body saying VENDOR ugslmd is exactly the section 4 mismatch.

8. Falling back to the trial

Legitimate while an entitlement is sorted out. Add to polarion.properties and restart:

com.siemens.polarion.license.salt.enabled=false

⚠ Enabling SALT against a server that cannot satisfy it is worse than the trial: Polarion starts either way, so the failure is invisible until someone tries to log in. If you enable SALT and it does not license, either fix it in the same pass or put this line back.

⚠ Restore any shared setting you changed while diagnosing. SALT_LICENSE_SERVER is machine-wide and other Siemens products read it. Leaving a diagnostic-shaped edit in a shared variable is how a mystery appears three weeks later.

9. The verification bar

A running Polarion service is not evidence of licensing. It starts unlicensed, on an expired trial, and fully licensed, identically. Accept only:

log4j-licensing-*.log naming the source you intended, with no error, and
saltd.log carrying a fresh OUT: "pln_..." user@HOST (served licences only), and
lmstat showing seats in use rather than 0, and
a real user logging in.

The end state that closed this out:

20:06:13 (saltd) OUT: "pln_alm_n" ed@MARTINI-GAMING
20:06:31 (saltd) OUT: "pln_alm_n" infodba@MARTINI-GAMING
Users of pln_alm_n: (Total of 25 licenses issued; Total of 2 licenses in use)

10. Where the documentation lives

Local help server, Polarion 2606 collection PL20251205943446859, manual Install and configure the SALT licensing server for Polarion, book id mzd1706003200646:

Topic	Id
Configure Polarion	`vdb1709734615662`
General SALT Server configuration notes	`ksq1710920059958`
Reactivate a License	`djx1709737619464`
Troubleshooting	`ood1706089317460`
Disable SALT licensing	`jea1725004198955`

Server log C:\ProgramData\Siemens\License Server\saltd.log; install logs C:\Program Files\Siemens\License Server\logs.

⚠ The Troubleshooting topic states that changing the node-locked file or path, or switching between node-lock and server licensing, requires a Polarion restart or a reactivate. It also notes the License Overview count is the summation across all configured sources, which is a hint that the combination rule in section 3 is real even though nothing states it outright.

11. The short version

Check salt.enabled=false is not present. It beats everything else.
Reduce SALT_LICENSE_SERVER to one source. Never diagnose with a list.
Read log4j-licensing-*.log line 1 to see which value actually won.
lmdiag the feature. If it checks out and Polarion still fails, the fault is client side, and the vendor daemon is the first thing to suspect.
missing server_id feature plus Invalid (inconsistent) license key from the two routes is the signature of a licence issued to the wrong vendor daemon. Ask for a reissue against saltd.
Never accept a running service as proof.

Generated from skills/polarion-salt-licensing/SKILL.md in the tc-automation-skills library, which is the canonical copy and also serves as the agent skill set for Teamcenter work.