System Administration Guide
Managing InterSystems IRIS Licensing
This chapter contains an overview of the InterSystems IRIS™ license system; it covers the following topics:
InterSystems Terms and Conditions
govern how you may use the licensed InterSystems IRIS software. Occasionally, the implementation may be more lenient. Verify that any license-related code you write conforms to these terms and conditions.
Each InterSystems IRIS instance maintains an independent local view of its license capacity and current use, and each instance requires access to a license key (except evaluation installations). You may install and activate a local license key file on each instance. Or, if you are managing multiple instances, you may configure a license server to manage key files stored in a central location, which it can then distribute to other instances. In this case, each instance must be configured with the LicenseID
of the key file, so that it can retrieve a copy of the key at startup.
Multiserver licenses can be shared among cooperating instances, either on the same machine or on different machines. Sharing is permitted only with multiserver keys. To use your multiserver licenses, you must configure one or more InterSystems IRIS license servers to allocate the InterSystems IRIS license units authorized by the key. All instances sharing a key must be configured to use the same license server or set of license servers. License servers can run on any computer where you run an InterSystems IRIS instance. A monitor process sends update messages to the license server, which coordinates license allocation when more than one instance shares a license.
The license server coordinates the views of license use maintained locally in every instance. The license server is not an InterSystems IRIS process; it is unaffected if an InterSystems IRIS instance shuts down. One license server can handle multiple instances. Therefore, you need at most one per host regardless of how many InterSystems IRIS instances run on a host. However, each InterSystems IRIS instance must have a local copy of the authorizing license key file installed.
If you run InterSystems IRIS servers on multiple hosts, you can configure more than one license server to provide redundancy. The license software selects one of the license servers to be the active server. The other servers are available to take over should the active server fail. When configuring license servers, decide which server or servers you want to host the license server. You can configure it to run on as many hosts as you want, but more than three is excessive. Since the license server is started by a running instance, it should be configured to run on systems where you expect an InterSystems IRIS instance to be running consistently.
Multiple instances with different license keys and running on different platforms can use the same license server to coordinate licensing as long as each instance has its own copy of the proper iris.key
file and all instances authorized by the same key use the same license servers. However license units are not summed across license keys. InterSystems IRIS instances using different license keys do not share license units, and users logged into two instances using different license keys will consume a separate license unit from each key.
Configure the license servers using the Management Portal:
Navigate to the [System] > [Licensing] > [License Servers] page.
This displays a list of license servers configured for this instance. When there are multiple license servers configured for this instance, the row of the active license server is shaded. From this page you can edit or delete an existing server definition or add a new server.
to configure a license server.
Enter a name for the license server in the Name
box, the IP address of the host on which it runs in the Hostname/IP Address
box, and the port number used by the license server in the Port
The license server name identifies the license server in the configuration and must be unique to a configuration.
The license server port number must be a number between 1024
; InterSystems uses a default port number of 4001
. The port numbers of redundant license servers running on different hosts do not need to be unique, but must be different from any port number used at that IP address.
Click the name of a listed license server to update the information described in the previous step.
to remove a license server from the configuration.
After adding or deleting a license server, you must restart the InterSystems IRIS instance.
If separate instances all configure the same license server address and port, they all use the same license server; when this is the case, you should delete the default LOCAL
license server (127.0.0.1) on each instance. If the same key is loaded on each instance, they share the key; if different keys are loaded on each instance, the license server serves each set of instances using each key separately.
In addition to managing the capacity of shared licenses, the license server may also distribute keys stored in a central directory to InterSystems IRIS instances.
A KeyDirectory property is defined as part of Config.LicenseServers
. If this is filled in, the Instance which starts the License Server will read any valid *.key files found there at startup, and send them to the License Server. Each key file must have a unique LicenseID
property. A count of files successfully loaded, and any errors encountered, will be logged. You will also be able to manually re-load key files from the directory to update any licenses by calling ReloadKeys^%SYS.LICENSE
from the %SYS namespace.
Loading a new key with the same LicenseID
as an existing key in the License Server key tables, will mark the existing key as "replaced". Requests from Instances for that LicenseID
will get the most recently loaded key. You can use the existing $System.License.DumpKeys()
method to view the current state of keys in the License Server.
InterSystems IRIS uses license keys to ensure proper operation of its registered sites, to define capacity available and to control access to InterSystems IRIS features. (License keys are not required for evaluation installations.) A license key is provided in the form of a license key file, typically named iris.key
After installing InterSystems IRIS, use the following procedure to activate your license key. You can always use the same procedure to activate a new license key (that is, upgrade the key) for any installed instance. You can activate a license key placed in any location accessible to the management portal; as part of activation, the license key is copied to the instance’s manager directory (install-dir/mgr
) as iris.key,
if it is not named that already.
To activate a license key, use the following procedure:
Navigate to the [System] > [Licensing] > [License Key]
page. Information about the current active license key is displayed. If no license has yet been activated, this is indicated, for example by the notation Customer Name: License missing or unreadable
. This page includes a
button to let you easily print the displayed information.
and browse for the license key file you want to activate. When you select a file, information about it is displayed so you can verify that you have the right license key before activating it; for example, that it provides the desired capacity, and has the right expiration date. If the key is not valid, this is indicated in an error message. If a license is currently active, information about the current and selected licenses is displayed side by side. If a restart of the instance after activation will be required for the license key to take effect, this is noted and the reason for it is provided. This dialog includes a
button to let you easily print information about both the current active license and the new license key you have selected.
to activate the new license key; it is copied to the instance’s manager directory as iris.key
, overwriting the previous license key (if any). A confirmation dialog reminds you to restart the instance, if required, and warns you if the new license will enable fewer features than the current license if this is the case.
Instances can be configured to request a license key from the license server by using the LicenseID
property of Config.Startup
. At instance startup, if there is no iris.key file present and the LicenseID
has been defined, then the instance will request and activate the license key from the license server.
The same LicenseID
must be in the license key file, as well as defined on the instance that needs to download a license
In general there is no need to restart the instance, but there are constraints when upgrading a license key. Automatic activation of the new key does not occur if you change license types from Power Unit to any other type; this should be a rare event.
Another constraint is the amount of memory the license upgrade consumes from the generic memory heap (gmheap
) space. If gmheap
space is not available, the number of license table entries cannot be expanded. If insufficient gmheap
space is available for a license upgrade, a message is written to the messages log. You can increase the size of the gmheap
setting from the [System] > [Configuration] > [Advanced Memory Settings]
page of the Management Portal.
If the new license key consumes at least 1000 64 KB pages more gmheap
space than the existing key, the InterSystems IRIS instance must be restarted to fully activate the new license key. However, since each page represents 227 licenses this situation is rarely encountered.
To update a license key, replace the key file in the KeyDirectory and run ReloadKeys^%SYS.LICENSE
. The License Monitor on each Instance (^LMFMON
) will check every 30 minutes to see if there is a different key for the configured LicenseID
, and if so, will try to perform an upgrade.
While most upgrades will succeed on a live system, some conditions could require an instance be restarted. The License Monitor will log an error in this case, and will not try to upgrade the key again until the next day (to avoid logging repeated errors). An instance restart will load the new key at startup.
If, after entering your license and restarting InterSystems IRIS, only one user can log in, use the management portal to investigate. The [System] > [License Usage]
page shows how many processes are running when you select
. You can also use the portal to display license information from the [System] > [Licensing] > [License Key]
page, as described in Activating a License Key
. If the key is not valid, the CustomerName
field contains an explanation.
You can also check the license error messages in the messages log and System Monitor log, which can be viewed in the portal on the [System] > [System Logs] > [Console Log]
page and [System] > [System Logs] > [System Monitor Log]
page, respectively (see Monitoring Log Files
section of the “Monitoring InterSystems IRIS Using the Management Portal” chapter of the Monitoring Guide
). System Monitor writes license expiration warnings and alerts to these logs, while Health Monitor writes license acquisition alerts and warnings. When the license limit is exceeded, alerts are written to the messages log by the licensing module. In Application Monitor, you can configure license metric-based alerts to send email notifications or call notification methods. See the “Using System Monitor
” chapter of the Monitoring Guide
for more information about these monitoring tools.
This document describes many of these methods. If your license problem prevents you from obtaining a terminal session, open a Command Prompt window run as Administrator, change to install-dir/bin
, and run the following command to get one additional terminal session within the Command Prompt window for license troubleshooting purposes:
method activates a new license key that has been copied to the installdir\mgr
directory. If all license units are consumed by users, preventing you from opening a Terminal window, you can run this method from the command line to activate a new license key with a greater capacity, as follows:
iris terminal <instancename> -U %SYS '##Class(%SYSTEM.License).Upgrade()'
You can also run the methods using the [System] > [License Usage] page in the management portal, as detailed in the following table:
You can also use the following class methods to display information or dump the license database to a file:
If you have developed REST based applications, your licenses will be consumed with use. To prevent this from happening, configure the number of Web Gateway connections that can be made. From the SMP in the Web Gateway Management section:
Set the Maximum
to a number 2 or 3 less than the license to allow for server-side logins.
Depending on the server side needs of the application you will need to adjust this.
By doing this when all the available connections are busy, new requests will queue up rather than being rejected. You will not see a rejection due to license counts being exceeded. As volume grows, the response time for the client will slow down. That would be the indication that you need to buy more licenses.
The following sections describe several other methods that show license information:
The subroutines listed below dump the contents of license tables contained locally in instance shared memory. In general, they identify the client:
An example of the contents of the all.dmp
License Capacity = 5, Current use = 2, Units Remaining = 3
0) User ID = 127.0.0.1, Connections = 2, CSP Count = 0, Time active = 90
1) User ID = 184.108.40.206, Connections = 1, CSP Count = 0, Time active = 49
An example of the contents of the inuse.dmp
License Capacity = 5, Current use = 2, Units Remaining = 3
An example of the contents of the piduse.dmp
PID Process LID Type Con MaxCon CSPCon LU Active Grace
592 System 0 0 0 0 0 0
2816 System 0 0 0 0 0 0
688 System 0 0 0 0 0 0
The following subroutines dump the contents of license tables maintained by the license server. The output files are in the indicated directory on the host where the active license server is running.
displays a summary of license information at the license server. The Distributed license use
section presents a collective view of license use for all InterSystems IRIS instances currently supported by the license server. The Local license use
section presents a view of license use for the single InterSystems IRIS instance in which the program is run:
Be aware that the information displayed by the local license methods is more up-to-date than the information shown by the license server methods; the license server is only updated periodically, while the local data is real time.
It is possible to exceed the license limit temporarily because login is controlled locally, but the license server enforces the limit. Each instance permits or denies logins based on its local license table which is maintained in instance shared memory. Each instance sends periodic updates to the license server describing changes to the local license tables. If the combined license use of all instances exceeds the limit, the license server sends a negative acknowledgment to update messages from each instance.
This negative acknowledgment causes each instance to refuse new logins because no additional license units are available. A login is considered new when the license user ID of the InterSystems IRIS process attempting to start does not match the license user ID of any current process. This state persists until the combined use by all instances falls below the authorized limit, at which point the license server begins sending positive acknowledgments in response to instance updates. The individual instances then allow new logins.
The InterSystems IRIS licensing system attempts to identify distinct users and to allocate one license unit per user. A user is identified by a license user ID, which can be an IP address, a username, a web session ID, or some other identifier depending on how the user connects.
Multiple processes started by or for a single user share a license unit up to the maximum number of processes per user. If the number of processes exceeds this maximum, a transition occurs and InterSystems IRIS begins allocating one license unit per process for that user ID. The system assumes that if the number of processes associated with a user ID exceeds the maximum, multiple users are accessing InterSystems IRIS through an intermediary (for example, a firewall system), so additional license units are required. (Processes started by the Job
command are counted under the user ID invoking the command.)
Even if the number of processes under the user ID drops back under the maximum, InterSystems IRIS continues to allocate one license unit per process for that user ID. Only when all connections by the user ID are closed and there are no more processes under the user ID does license allocation reset to one unit for that user ID.
InterSystems expects that most applications are moving to identify their users by name, eliminating problems associated with using a default user ID based on client IP address, web session ID, or other connection-derived user ID.
For example, when firewall or terminal server software is used, InterSystems IRIS cannot differentiate among connecting users, so it falls back on the maximum-connection transition rule. Using mixed connections from the same client also makes it impossible to count users appropriately using automatic ID creation.
When the username serves as the license identifier, these problems disappear. The importance of accurate user identification is expected to grow as organizations implement new access and audit requirements. Using the user identity to control license compliance is a natural corollary to this trend.
This section covers the following topics:
There are two modes of license login: automatic and explicit. Automatic login is the default. The licensing system attempts to identify the IP address of the client and uses it as the license user ID. This works well when clients connect directly to the server using IP. It does not work well if a firewall intervenes between the client and the server; all clients appear to have the same IP address. When a terminal server is used with the telnet protocol, automatic login cannot differentiate among users because InterSystems IRIS sees a single IP address for all terminal server ports. Since all connections originate from the same address, all connections have the same user ID. If users connect through a firewall or use the telnet transport from terminal servers, use explicit logins.
When IP is not used as the network transport, the IP address is not available for use as a license user ID. In these cases, the licensing system uses a variety of other sources as the license user ID. Batch processes started by the at
daemon on UNIX®/Linux systems pose another special case. Such processes do not share a license unit because they are not associated with a user. For these processes, the process ID is used as the license identifier.
When you select explicit login, InterSystems IRIS does not attempt automatic user ID detection. The application must explicitly call the $System.License.Login(UserIdentifier)
method to supply the license user ID and acquire a license.
Enable explicit login by calling the $System.License.DeferUserIdentification([0 or 1])
function. You can make this call from the SYSTEM
entry point in the ^%ZSTART
routine at system startup. If the argument value is 1
, license acquisition is deferred at login, so an explicit login can be performed. If the argument value is 0
, license acquisition is automatic at process startup.
When you defer login you must call the license login method immediately. A process that has not performed a license login pauses after its first 4000 ObjectScript commands, and then every 1000 ObjectScript commands after that.
Use an explicit login for any case that automatic login does not handle. It is important to remember that, even if automatic login is configured, it is always possible to call $System.License.Login(UserIdentifier)
to use explicit user identification for licensing purposes.
You can use the value of $USERNAME
to identify users for licensing. This enables more accurate counting in situations where you cannot use only the IP address to reliably identify distinct users.
For example, the following displays whether username licensing is currently enabled or disabled:
Write " Username Licensing",!
Write " 1-enabled, 0-disabled",!
The following example enables, then disables username licensing:
Bear in mind the following special considerations concerning license logins:
Application licensing enables InterSystems application partners to take advantage of the InterSystems licensing capabilities for their own licensing purposes. InterSystems IRIS manages customer application licenses just as it does its own application licenses, maintaining usage counts and acquiring and returning user licenses as needed. Application licenses consumed by a process or a web session are automatically released along with the InterSystems IRIS license consumed by the process or session when a process exits, halts or is deleted from the process table, or when a web session times out or is deleted.
The application licensing API
includes methods and queries that enable applications to consume and return licenses on behalf of a user and programs to obtain information about application and feature licensing, including the number of licenses in use and still available.
In the following sample application license, the customer uses keyword=value
pairs to limit the number of licensed users for several application features and enable the Extended Lab Reports feature for all users.
Extended Lab Reports=Enabled
An application license is not protected from tampering by InterSystems IRIS, but it can be protected by custom application code. For example, a checksum can be embedded in the keyword section and validated by the application prior to activation.
Content Date/Time: 2019-07-17 06:47:30