Activation of a Rehostable license fails with a -148 (NO_REHOST_TOP_DIR) error

On Windows, RLM stores persistent data in the "system_drive:"\Documents & Settings\All Users\Reprise directory.

If your system is set up such that permission to this directory is denied for non-admin users, then non-admin users will not be able to create (or use) rehostable licenses.

If this is the case, login to the system as an administrator and set the permissions so that all users can read and write to this directory.

Note that you might see a similar error when using a roaming license or when attempting to start the license server.

Also note that deleting, copying, or otherwise modifying this directory will lead to problems later.

Failover License Servers – why can’t I have 3?

The question often comes up - "I am used to failover servers configured in a triad (3).  Why can't RLM support this?"

Whenever this happens, it is because someone is used to the way that FLEXlm configures redundant servers.

The reality is this - RLM and FLEXlm work differently with respect to server failover,  and the RLM method is easier for the end-user to configure, while providing the same amount of server redundancy.  In a FLEXlm redundant-server configuration, a little-known fact is this:

the third server can never serve licenses

This is because, in FLEXlm, 2 of the 3 servers must be running to have the system operate.  So, either servers 1 and 2, 2 and 3, or 1 and 3 must be running.  And FLEXlm (at least until version 10.?) always picks the server whose name is first in an alphabetical sort (we know, we wrote the code).   So the server with the last name, alphabetically, will never serve licenses.

By contrast, with RLM, you pick a primary license server, and a failover server.  If the primary goes down, the failover takes over. There is no 3rd server to configure.  There is no situation where 3 FLEXlm servers would serve licenses that RLM will not serve licenses (assuming RLM is configured on 2 of the 3 FLEXlm servers).  In other words:

adding a 3rd RLM server buys you nothing, other than extra administrative overhead

Application cannot connect to license server

Sometimes, after completing the installation of your new software, the application refuses to run, giving you a "Can't connect to server" error.  When this happens,  the error message will look similar to the following:

Usually, this means one of the following has happened:

• The license server is not running
• The hostname or port # on the application's computer doesn't match where the license server is actually running
• The license server (rlm) is running, but the ISV server for your application isn't running for some reason
• A firewall is blocking access to rlm or the ISV server
• The license server machine is down

The first step in diagnosing this problem is to find out where the application thinks the license server should be running.  The most accurate way to do this is to use rlm diagnostics with the application.  Since RLM v8.0, every application which uses RLM has built-in diagnostics.  The procedure for running diagnostics is described in this article:

http://www.reprisesoftware.com/blog/?p=1909

Once you know the hostname and port of the license server, you should log in to that host and verify if the license server is running.  You should see one process for the "rlm" generic server and a second one for your ISV server.  Depending on whether the ISV server is a binary or a settings file, the process listing will be a bit different.  On Unix systems, for an ISV server implemented as a settings file, the two process will look similar to the following (this is for the "reprise" ISV server):

For an ISV server binary, the output will look more like this:

In the windows task manager, you will see either 2 rlm processes or 1 named rlm and one with the name of your ISV server:

• If you can find rlm running, but not your ISV server, you will need to look at the debug log from rlm to see why the ISV server isn't running.   The simplest way to do this is to run rlm in a command window (on Windows) or from the shell on Unix.    Go to the directory where the license servers are installed, and run the command "rlm".    If the problem is not apparent from the output of rlm, you should contatact the ISV who supplied your software - they should be able to help you get the servers running.

• If both rlm and ISV servers are running on the server node, the problem could be that either you have a firewall installed on the server node which is not allowing your application to access either the rlm port, or the port of the ISV server.   If this is the case, configure your firewall to allow access to port "xxx", and you can configure RLM to use a fixed port number for the ISV server by specifying the ISV server port, xxx,  on the ISV line as such:

ISV isvname port=xxx (if you have RLM v9.0 or later), or

ISV isvname isv-binary isv-options-file xxx (if you have pre-v9 RLM)

If  you see another cause of this problem, or have a different solution, please leave a comment.

My license server won’t start

One common problem we see at Reprise is the issue of license servers (especially the ISV server) not starting.  When this happens,  the debug log will look similar to the following:

When this happens, it is usually (99.999% of the time) the fact that another copy of the ISV server is running (in this case "isvabc").  Use the task manager (on Windows) or "ps -ax" (on Unix) to find the other copy of the server that is running, and, if necessary, kill the old copy (don't forget to kill the rlm server that started it, too, otherwise that copy of rlm will just re-start the ISV server and you'll be back to where you started).

Note that a similar situation can occur for rlm itself, if you try to start a new copy of rlm on the same port as another copy.

If you need to run multiple ISV servers (and/or multiple copies of RLM) see the article "Managing Multiple-ISV Installations" here .

I can’t check out a license, but I can get to the admin interface on the server – what do I do?

I can't check out a license, but I can get to the admin web interface!

In some cases, a floating license cannot be checked out from a particular computer, yet that same computer can view the admin web interface from the license server.

In very early versions of RLM (prior to RLM v3.0), the most common cause of this failure is that the "normal" hostname of the server node is unknown on the client machine.

So, for example, if you server node's hostname is "server", but it is more generally known as "server.mycompany.com",  and on the client computer it is only known as "server.mycompany.com", you will see this behavior.

In more recent RLM versions, the most likely cause is that the hostname in the local license file is not the same as what you typed into the browser.

OK, how do I fix it?

If your rlm software is newer than v3.0, the best way to figure out what is happening is to run rlm diagnostics (available in RLM v8.0 and later).

To run client-side diagnostics, set the environment variable RLM_DIAGNOSTICS to the name of a file, then run the application:

% setenv RLM_DIAGNOSTICS filename

% (run application)

The file "filename" will contain the diagnostic information.  It will look similar to the following:

Near the bottom, you will see the name of the license file that the application is using as well as the server's hostname.  If this is different from the name you use in your browser, correct the license file and try the application again.

If you have a pre-v3 version of RLM, you might also want to put the server's IP address into the license file on the server side.  So, instead of:

HOST server hostid port#

use a line like this:

HOST server_ip_address hostid port#

For example, instead of:

HOST  server  12345678  5053

use

HOST  192.16.7.12  12345678  5053

My License Server Reports too many licenses in use

One situation we hear about on a regular (but infrequent) basis is similar to the following:

"My license server reports multiple licenses checked out from the same person, yet I know that this person is only using one license.  Why is this?"

As a general rule, this results from users removing laptops from the corporate network, then re-attaching later.  But it could occur any time a machine is either removed from the network, or shut down improperly.

The reason this happens is that the license server machine does not detect that the client side of the connection has been terminated.  This is an unfortunate aspect of TCP/IP, and it will vary on different platforms.

Fortunately, there is a simple solution to this problem - the TIMEOUT option in the ISV options file.

If this happens only on a single product, you can add a line similar to the following:

TIMEOUT 3600 the-one-product-with-the-problem

This would cause licenses for "the-one-product-with-the-problem" to be timed out after 1 hour of inactivity.

Alternately, if this happens to many products, you could add the line:

TIMEOUTALL 3600

This line would cause all products from this ISV to time out after one hour of inactivity.

Either of these lines would be added to your ISV options file - by default "isvname.opt" (where "isvname" is the ISV server name), contained in the directory with the license server binaries.  Alternately, you can specify any option filename you like on the ISV line in the license file.   Don't forget to do a reread on the license server after you edit the options file.

One last thing - your ISV can control the minimum timeout time for any individual product.  By default, this is 1 hour in RLM (3600 seconds).  However, if the ISV specifies:

min_timeout=xxx

in an individual license, then that minimum time would apply even if you attempt to set a shorter timeout time.

Managing Multiple-ISV installations

When you have licensed software from multiple ISVs, you have two choices for how to configure rlm and the ISV servers when running them on a single license server system.

The first choice is to keep them entirely separate, using separate installation directories and port numbers, for example:

Advantages:

• conceptually simple

Disadvantages:

• The two rlm client connection ports and web server ports will have to be managed so that they don’t collide.
• Users of the rlm web interface will have to remember which port number goes with which.
• The default rlm client port numbers as established by the ISVs (in the license files or environments on all the client machines) will need to be changed, for at least 1 ISV.

The second choice is to  run a single instance rlm, which manages two (or more) ISV servers.  This is the method recommended by Reprise Software. For example:

Advantages:

• Only a single RLM port need be managed.  If a new ISV is added with a new port, the single copy of rlm adds this port to the list of ports it listens to.
• A single web interface is used for all ISVs.
• No client-side changes need to be made for any ISV.
• Simple, straightforward method to add a new ISV, when the time comes.

Disadvantages:

• You must be sure to always select the newest version of rlm (rlm.exe) and the utilities that any of your ISVs use.

The simple way to accomplish this is to copy one vendor’s server-side files to the other
vendor’s server directory.  Or create a central repository of rlm server side files. The files necessary are:

• rlm[.exe]. Use the latest version from all the vendors involved, or better yet, get
  the latest from http://www.reprisesoftware.com/enduser_kits/end-useragreement.php
• <ISV>[.exe] or <ISV>.set from all vendors
• *.lic from all vendors
• Command line utilities such as rlmstat[.exe], rlmdown[.exe], etc. As with rlm[.exe] use the latest from the vendors involved, or download from:  http://www.reprisesoftware.com/enduser_kits/end-user-agreement.php