Troubleshooting and FAQs

This section is divided into two parts. Click the appropriate link to view questions and answers relevant to that.

>Migration from License Manager v8.2.0 to v9.3.0 or Later

Unified API FAQs

Question: For a commuter license checked out using Traditional API, is it possible to return the commuter code using Unified API?

Answer: Commuter code checked out using Traditional API can be checked in only using Traditional API and vice-versa.

Question: Why do I need to set up the persistence data?

Answer: Persistence data is the licensing data that is retained on the local computer in the non-volatile storage. Licensed applications may need to refer to this data during their lifecycle under different circumstances, even beyond the expiration of a license or to manage the security of certain licensing models.

For example, persistence data ensures that a trial license cannot be re-used by your customer after it is exhausted, by such means as setting the system clock back or by uninstalling and then re-installing the application. To run the licensed application again either a new trial license or a normal license is required. You must configure your customers’ systems to allow persistence data creation.

For a list of licensing models that require persistence data, refer to the Persistence Data-Dependent License Models section.

NOTE It is mandatory to initialize the persistence files before installing the commuter authorization code; otherwise error 210084 will be returned while installing the commuter authorization code.

Question: How can I set up persistence data on (License Manager) clients or standalone systems. Do I need administrative privileges to create persistence data?

Answer: Use the sntl_persistence_create API to set up persistence information on (License Manager) clients or standalone systems. Administrator privileges are required to create persistence data.

Traditional API FAQs

Question: I have allowed commuting of a server-locked license. Since the server locking criteria will not match the fingerprints of my client system, will it be possible to run the application while traveling?

Commuter license authorizations are locked to a portable computer based on any of the following criteria:

>Local request locking criteria

>Client locked criteria

>Client-server-locked locking criteria

The commuter license does not depend on the server locking criteria. Even if the server locking criteria does not match with the client system fingerprints (provided your client system fulfills the commuter license locking criteria), the client system can use the commuter license. The server-locked criteria only restricts license installation on a particular License Manager system. In other words, if the license is server-locked, then it must be installed and issued by a License Manager meeting the server locking criteria.

Question: I am already traveling and need a license to run the application. Can I use echoid to generate the locking code of my laptop?

No. The commuter locking code used to lock a commuter authorization is not the same as the locking code displayed by echoid. You should use WRCommute or rcommute.

Question: Can I return back a license that was remotely commuted?

No. A remotely commuted license cannot be checked back into the License Manager. It simply expires on the remote computer.

Question: I have already commuted a license authorization, but due to some reason I lost the authorization. Can I again check out the authorization for the same license?

Yes. You can check out the authorization for the same license if the tokens of the license are available. However, if you check out the authorization from the License Manager from where it was originally checked out, the token count on that License Manager will not decrement. If the authorization for the same license is checked out from a different License Manager, then the token count will decrement.

Question: As a system administrator, I want to set different limits for different people for the same license. Is this possible?

Yes, you can set different limit for different people for a license. There are two ways to do this:

>Method 1 - At the time of license generation, you can identify the clients who want to use commuter licenses. You can ask for the lock code of those client computers, add them, and then set up the license for each client node.

>Method 2 - Your customers can also set the limit at their site by using the group reservation feature. They can use the Sentinel RMS Wlsgrmgr utility to create reservations for a license. Using this utility, you can limit the use of a license to a group or an individual. For more details on the group reservation feature, refer to Sentinel RMS SDK System Administrator Help.

Migration from License Manager v8.2.0 to v9.3.0 or Later

My customers are still using the v8.2.x of the License Manager. Can these installations migrate seamlessly to the latest version of the License Manager?

Upgrading the License Manager to v9.3.0 (or later) migrates the commuter licensing data automatically.

During the migration process, the License Manager will not serve any requests. Therefore, it is recommended to make the License Manager unavailable for licensing requests and update activities during this period.

Post-migration if the License Manager version is downgraded from the upgraded version, commuter licensing becomes unusable.

Thales recommends that all checked-out tokens should be checked-in before migration.