About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
Bring the licence server back on a machine whose identity still matches the signature, and bring it back before the applications that must check a licence out. A restored application can pass every other test and then refuse to start, because the thing it asks for permission is down, or because you restored that thing onto a computer the licence does not recognise.
This article uses one primary source, the Reprise License Administration Manual for RLM release 15.2.0, dated 9 January 2024. Other publishers use other licence managers. Where this manual is specific, the article says so. It does not tell you the commands to start a server, and it does not describe operating-system activation.
Why it matters
A licence server is a shared resource. NIST SP 800-34 Rev. 1 times a shared resource by the harm its absence does to everything that depends on it. For a fresh checkout requiring the server, an unavailable server can prevent startup. Existing checkouts, permitted roaming and publisher-specific grace behaviour need separate assessment; an outage does not prove every running application stops immediately. The virtual machine, the database and the file share can all be fine. The estate is still stopped.
The manual separates licences that need this server from licences that do not. A licence with a non-zero count always requires a HOST line. An uncounted licence does not require one, and even if a HOST line is present the server's identity is not part of that licence's signature. A node-locked licence can be used only on the node named by its own identity. If it is uncounted, or if it is the manual's "single" form, the software only has to confirm it is running on the right computer, and no licence server is required. A counted licence exists so that a server can keep a count of how many are in use. The manual is explicit that a count of one is still a counted licence and still needs a server. The word "single" is a different thing, and servers will not process it.
So the first planning fact is a list, not a rebuild. Products requiring a fresh server checkout can be blocked while that server is unavailable. Products on uncounted node-locked licences stop when they are not on the computer they were locked to. Those are different gates, and a recovery that treats every product as "needs the floating server" will chase the wrong machine.
How it works
The identity is part of the signature
On the SERVER line, the hostname is not an input to the licence-key signature, and the manual says it can be changed at any time. The hostid is RLM's idea of the computer's identification. It is an input to the signature, so it cannot be changed. For ordinary server-counted licences, the signed hostid must match. The manual separately exempts uncounted licences from the server-hostid signature input. Moving a counted LICENSE line under a different signed HOST identity can invalidate it; copying it into a file with the same applicable identity is not inherently invalid.
That is the recovery constraint. You can rename the restored server. You cannot present a different hostid and expect the same file to be accepted. The manual's own status list includes "Invalid hostid on SERVER line". A virtual machine restored onto hardware or a hypervisor that changes the identifier the product uses as a hostid is a different computer, even when the disks came across intact. Our recommendation: before the recovery, record the hostid the current server reports, and record which kind of hostid the publisher used. After the restore, compare. If they differ, the file you restored will not serve, and use the publisher’s authorised rehost, reissue or supported failover process. Availability of a customer self-service workflow depends on that publisher. Put that wait on the plan. Do not fill it by editing the signature.
A node-locked uncounted licence has the same kind of lock on the client. Restoring that application onto a new identity fails the local check, with no server involved. The recovery of the application and the recovery of its licence are the same act only when the identity comes with it.
Failover is a licence the publisher issued, for a server that is down
RLM can have one server take over the licence complement of another server that has gone down. The manual calls the failed one the primary and the other the failover licence server. While the failover server is serving those licences, roaming operations are not permitted on them. The manual notes that there cannot be a firewall between the two servers, and that failover servers are not supported on HP-UX or IBM AIX.
The capability is not implied by owning two machines. The publisher enables it per customer, with a failover licence in the file of the server that is to take over. One form checks that the primary machine is down. Another checks that the RLM process on that machine is down. A third also requires an activation from the publisher's activation server before the takeover proceeds. The failover licence carries the hostid of the primary. Reprise recommends that the failover server have no licences of its own, and stand by until it is needed.
Read that against a recovery where both copies come up because both sites were restored. The documented takeover is for a primary that has gone down. A correctly licensed failover server can already be running in standby while the primary is healthy; the takeover condition controls when it serves the primary’s licences. Our recommendation: one serving instance of a given complement. Prepare and run the standby according to the publisher-issued failover configuration, and verify the primary-failure condition before takeover. Do not wait until an outage to invent a second serving instance. Two restored copies, both reading a copied file, are not a pair the manual describes.
A transfer is the opposite of a disaster copy
The manual also describes moving a set of licences from a source server to a destination, for example so a project on the far side of a slow link can check out locally. When they are transferred, they are no longer available at the source. They stay available at the destination only while the source is up. If the source goes down, or the network loses connectivity, the destination loses the transferred licences.
That sentence is the one to underline in a recovery plan. A transfer looks like a second server. In the failure you are planning for, the source is down or the path is gone, and the destination's borrowed licences disappear with it. Our recommendation: do not list a transfer destination as the licence service for the alternate site. It is a capacity move for a live source. The alternate site needs its own signed file, or a failover licence the publisher issued, or a reissue. It does not need a transfer that the manual says will not survive the outage.
Time, because expiry is local
For a floating licence, the expiration date and time are in the server's local time. For a node-locked licence they are in the client's local time. A wrong clock can cause incorrect expiry decisions or trigger the product’s clock-windback protection, and the application error will talk about the licence, not about the clock. The estate order in the companion discussion of time applies here in one concrete way: believe the server's clock before you believe a floating expiry. The manual also documents clock-windback detection, including possible false positives; it does not establish a universal safe clock-error margin. Our recommendation is the strict one. Synchronise the licence server to a source you trust before applications start checking out, and do not "fix" a false expiry by editing the date in the file. The date is inside the signature.
What to choose and why
These are our recommendations for this licence manager. Another publisher's manager can differ, and the difference matters.
| Situation | Reasonable choice |
|---|---|
| The product uses a counted licence | The server is on the critical path. Restore it, on a matching hostid, before the product |
| The product is uncounted or "single" and node-locked | There is no server to restore. The client's identity has to match the lock |
| The restored server has a new hostid | Stop. The signature will not follow. Ask the publisher for a reissue. Do not edit the key |
| Only the hostname changed | The manual allows that. The hostid is the value that must match |
| Both sites restored a copy of the same server | Avoid two uncoordinated serving copies. A licensed standby may run beside the primary and take over only under its configured conditions |
| Someone set up a transfer "for DR" | Do not rely on it. The destination loses those licences when the source or the path fails |
| A floating licence shows as expired immediately after restore | Check the server's local clock before you treat the licence as finished |
| You do not know which products are counted | Make the list from the licence files before the outage. The count and the word "single" are different |
Risks and limits
- This is RLM 15.2.0, dated 9 January 2024, from the publisher's administration PDF. FlexNet and other managers were not opened. A rule above that is not in your publisher's current manual is not a rule for you.
- Failover is optional and publisher-issued. Owning two servers does not create it. One form also needs the publisher's activation server, which is a further dependency during the takeover.
- The manual says there cannot be a firewall between a failover pair, and that the feature is absent on HP-UX and AIX. Treat that historical product constraint as a design issue to resolve with the publisher for the actual release; this article does not recommend disabling a firewall or weakening network controls.
- Hostid types differ. The manual points at a list of hostid kinds and a tool that prints the hostid of the machine it is running on. Which kind your publisher used is a fact about your file, not a fact this article can see. Compare like with like.
- No server was started, and no licence was checked out. Error text in a product can have causes other than the ones quoted here. "Invalid hostid on SERVER line" is the manual's status for that case. It is not a promise about the wording your application will show.
- NIST does not describe licence servers. It is cited for the shared-resource reason to put this service in the order at all.
Research and verification
Drafted with AI assistance on 11 November 2026 and independently source-reviewed on 13 November 2026. No article commands or recovery operations were executed. This is educational source research, not a lab-validated production procedure.
Sources
Independently reopened 13 November 2026.
- Reprise Software, License Administration Manual, RLM release 15.2.0, 9 January 2024: PDF. Hostid and hostname on the SERVER line. Counted licences and the HOST line. Node-locked, uncounted and single licences. Failover licence servers, section 2.4. Licence transfer, section 2.5. Floating expiry in server local time. Status for an invalid hostid on the SERVER line.
- NIST SP 800-34 Rev. 1, May 2010: PDF. Recovery priority of a shared resource.
This article was originally published on .