Jump to: navigation, search

Technical Licensing Concepts

This topic describes the main components of the Genesys licensing system, which is implemented via License Server Manager, and explains how this system works. Information in this topic is divided between these subtopics:

License Server Manager

The FLEXlm/FlexNet Publisher License Server is a daemon process that runs continuously in the background, tracking how many instances of Genesys licenses are utilized on a network.

The License Server consists of a License Server Manager and the Genesys vendor daemon.

At startup, all licensed Genesys FlexEnabled applications establish a client connection to License Server, providing a computer host ID or IP address, along with various information about the application. If License Server finds a valid license for the application, it permits the application to start and run properly.

The license server responds to a FlexEnabled application's checkout request for a license if licenses are available. The license server counts the number of licenses that are in use and the number of licenses that are still available. The server can also provide reports on which licenses are being used and by which users.

While licensed applications run, the License Server and FlexEnabled application send polling messages to each other at certain intervals. The license server or FlexEnabled application can therefore know if the application or license server has terminated abnormally. If the application terminates because of a process or runtime environment failure, the license server records the information about the license(s) no longer being in use.

FlexNet Publisher License Server

About FLEXlm and FlexNet Publisher

Genesys License Manager incorporates the FLEXlm 9.5 license manager, and the FLEXlm FlexNet Publisher 11.7 and 11.9 license managers inherited and developed by Flexera. FlexNet Publisher is the successor product name for FLEXlm, and is highly backward compatible with earlier FLEXlm versions. For the purpose of simplicity, these are referred to as "License Manager", or "Flex", generically, whether FLEXlm or FlexNet Publisher.

Beginning with Genesys Release 8.1, a new version of License Manager is required for use of Genesys products with certain, newer, 64-bit operating systems, as shown below.

Genesys License Manager Requirements Table

Operating System Bit Mode License Manager Version Management Framework Version Flex lmutil Version
  • Windows Server 2008 R1 and R2 2012
  • Red Hat Linux 5
64-bit native FlexNet Publisher 11.9 Management Framework 8.1+ lmutil 11.9+
Windows Server 2008 32-bit
  • FlexNet Publisher 11.7


  • FlexNet Publisher 11.9
  • Management Framework 8.0.2+
  • Management Framework 8.1+
  • lmutil 11.7+
  • lmutil 11.9+
All other Genesys-supported OS versions not listed above 32-bit
  • FlexNet Publisher 9.5


  • FlexNet Publisher 11.7


  • FlexNet Publisher 11.9
  • Management Framework 7.1+
  • Management Framework 8.0.2+
  • Management Framework 8.1+
  • lmutil 9.5+
  • lmutil 11.7+
  • lmutil 11.9+
  • For 8.x versions of Genesys software, License Manager version 11.7 or later should be used.
  • When using License Manager version 11.7, you must also upgrade to the Licensing Admin tool lmutil version equal or higher to that version.
  • During licensing platform upgrades, a rollback is possible for most supported license control configurations. However, the Genesys 7 licensing platform does not support IPv6, or some of the newer operating systems.
  • + means the indicated version plus all later versions.

For mixed environments and incremental migrations, FlexNet Publisher 11.x is fully backward-compatible with existing 7.x and 8.0 applications. For example: If you are running CIM Platform 7.x or 8.0 and other 7.x or 8.0 applications, on Windows Server 2008 64-bit native, and wish to migrate to Release 8.1 while continuing to run your other existing Release 7.x or 8.0 Genesys 32-bit applications in parallel, you may do this by upgrading to FlexNet Publisher 11.9. You may migrate the Release 7.x or 8.0 applications at a later date.

Licensing Vendor's Documentation

Genesys provides vendors' documentation: License Administration Guide - FlexNet Publisher Licensing Toolkit 11.9, in the License Manager installation package.

License Manager Components

The License Manager architecture contains these components (see Licensing Process):

  • License Manager (LM) daemon
  • Genesys vendor daemon
  • License file
  • Application program

Licensing Process

The above figure depicts a generalized disposition of the licensing system components. In reality, the license file reside on the computer running License Manager; a copy of the license file may reside on the computer running a Genesys application; and the application may run on the same host as License Manager.

License Manager Daemon

The LM daemon (lmgrd ) executes two major tasks. First, it initiates commerce with the client applications, passing the connection on to the appropriate vendor daemon. Second, it starts and restarts the vendor daemons. Genesys maintains the Flex capability of running multiple redundant License Manager daemons on three server nodes, so that licenses are available if any two of the three nodes are running (see Three-Server Redundant Configuration for details).

Genesys Daemon

Licenses are administered by running a process called the vendor daemon, which records how many licenses are checked out and who has them. If the vendor daemon terminates for any reason, all users lose their licenses (this does not mean the applications suddenly stop running). Users normally repossess their licenses automatically when lmgrd restarts the vendor daemon, although they may exit if the vendor daemon remains unavailable. The Genesys daemon is called genesys.d for and genesys.d.exe for Windows.

Client programs communicate with the Genesys daemon through TCP/IP network communications. Genesys applications and the daemon processes (the license server) can run on separate hosts on a single network (local area) or across a wide-area network of any size.

A combination of the LM daemon (lmgrd) and the vendor daemon (genesys.d or genesys.d.exe) comprises the license server.

License Files

Licensing data is contained in a text file that Genesys creates, but which you edit and install. Genesys recommends saving this file under the name license.dat; however, this is not mandatory. The editing procedure is described in Editing the License Data File.

The file contains information about the license server host name, license server host ID, license server port, vendor daemons, and one or more lines of data, called a FEATURE line, for each licensed product. You can edit a license data file by adding FEATURE lines for new product licensing, even if the products belong to different vendors.

If more than one FEATURE line with the same name appears in a license file, License Manager produces an error message in its log,grants a license for the first FEATURE line, and ignores all other instances of the same feature. Remove extra FEATURE lines or comment them out with the pound sign (#).

As long as License Manager can access the license file, the file can reside on a computer other than the one running License Manager.

  • Genesys no longer issues new sentinel keys (also called dongles). If you have dongles that you have used in your previous Genesys installations, refer to the Licensing Genesys Products document on the Genesys Technical Support website. That document provides the description, installation instructions, and license file example for dongles.
  • License files for License Manager v11.x are the same format and are backward compatible with Genesys Release 7.x and Release 8.0 applications. If you are implementing License Manager 11.7 or 11.9,new license files may be required, and may include a mix of Release 8.1, Release 8.0, and Release 7.x products, as needed.


At launch, Genesys server applications that require technical licenses connect to the license server and request a license. For this connection to occur, you must inform applications about the license server location. Specify the license server location by using a command-line parameter or the license-file option you configure for an application.

For detailed information, see Installing License Manager.

License Check Process

When you launch a Genesys application that requires a license:

  1. The application (client) determines which computer runs the license server for that product by either:
    • Taking license server parameters, if available, directly from the startup command line or the license-file configuration option.
    • Reading the license data file to determine the license server parameters.
  2. The client establishes a connection with the license server and requests a license.
  3. The license server checks the license data file to determine the total number of application licenses and compares it with the number of licenses currently in use.
The license server must read the same license data as the licensed application. That means, the license file describing all licensed Genesys products must be saved to or be accessible from the computer on which License Manager runs.

If a license is available, the license server returns license granted to the client and the application starts operating.

If no licenses are available, the license server sends license denied; the application generates an appropriate log message (log event #00-07100 Licensing Violation ) and exits.

Notes on Application-Specific Behavior

The following sections document any deviations in application behavior from the standard license checkout process.

Genesys Desktop

Genesys Desktop Server checks out a user-specific license (either Genesys Agent Desktop or Genesys Supervisor Desktop) when a user (either an agent or a supervisor) submits login parameters to start a web session. If a license is not available, the desktop window does not open. The server closes the user's web session and checks in the license when:

  • The user logs out using the logout command.
  • The user closes the browser window.
  • The browser terminates abnormally.

Genesys Desktop .NET Toolkit

Genesys Integration Server checks out a license of the connection type when a client tries to open a connection. If a license is not available, the connection is denied. The server checks in the license when the connection is closed, either at a client's request or because of the timeout.

Outbound Contact Server

At startup, OCS checks out as many licenses as are specified by its num-of-licenses configuration option (providing this amount does not exceed the amount specified in the license file). When the number of agents logged into Queues associated with one or more loaded Campaign Groups reaches the number of licenses checked out, OCS generates the Licensing Violation message: reason for the violation is that the feature usage level has been exceeded for every new agent that has logged into the campaign-related Queue. When an agent currently associated with a loaded Campaign Group logs out of the Queue or OCS unloads the Campaign Group, OCS reuses these freed licenses for new agents (and, if the licensing violation has been reported, removes it).

Because OCS controls the licenses while the switch (through the ACD Queue configuration) or URS (through routing strategies) controls the distribution of an outbound call, the agent who is denied the license may receive the call. As a result,

  • The corresponding Agent Desktop application does not interact with OCS to process the Calling List record associated with the call.
  • The number of agents that OCS uses in predictive-dialing calculations may be smaller than the real number of agents receiving outbound calls.


When T-Server receives license denied at startup because it has requested more licenses than are currently available, it checks out the maximum number of licenses that are available. If a single license is not available, T-Server generates the Licensing Violation message and exits.

To ensure that T-Server does not initially request too many licenses, set the corresponding T-Server configuration options to values less than the total number of T-Server-related licenses you have purchased. Pay particular attention to these option settings when using more than one T-Server.

Universal Callback Server

Initial License Checkout

UCS licenses are checked out at startup. The maximum number of licenses that can be checked out is specified in the configuration.

Available licenses are decreased upon receiving a callback request or when a license has been blocked. The decrease is incremented 60 minutes after the callback submission or the license block.

License Manager does not allow you to check out more than 9999 licenses per client; due to this restriction, one Universal Callback Server can handle no more than 9999 callback requests per hour. If the traffic of your anticipated callback requests is higher than this value, consider running several UCSs and spreading the load between several Routing Points.

For further information, see "Request for Service Availability Extension" section in the corresponding version of Voice Callback Deployment Guide, and the "Client-Server Protocol Extension" section in the corresponding version of Voice Callback Reference Manual.

Processing Request to Work in Unlicensed Mode

UCS produces a GCTI_LICENSE_FAIL licensing-violation log message with violation type in the following situation:

  • If vcb_preview licenses are available but the call arrives on a CDN (Route Point) that is configured for Autodial mode.

See the corresponding version of Voice Callback Reference Manual for details on how to configure Autodial on CDNs.

Universal Routing Server

At startup, URS checks out all available licenses. When a logged-in agent appears as a valid target for a call for the first time, URS allocates one of the checked-out licenses to the agent. When the number of logged-in agents that at least once appeared as valid targets reaches the number of licenses checked out, URS generates the Licensing Violation message for every new logged-in agent. An allocated license is freed for URS to reuse when:

  • The agent logs out.
  • The Person object describing the agent is disabled or deleted in Configuration Manager.
  • URS is restarted.

In the first two cases, URS may generate a Licensing Restored message.

Take this URS behavior and the fact that agents cannot manually give up licenses into account when determining the number of required licenses. This recommendation especially applies to sites that have many shift changes where new agents log in while the previously working agents have not yet logged out.

Interaction Server

For each license FEATURE name there is an Interaction Server configuration option with the same name in thelicense section. The value of each such option is a number specifying the number of licenses of that type that Interaction Server checks out. Interaction Server checks out the configured number of licenses of each type at startup. It also reacts to any value changes of the options in thelicense section.

If the number of licenses in use goes above the configured number of licenses (as a result of logging in agents), Interaction Server forces logout of some agents so that the number of licenses in use is equal to the configured number.

Licensing Violations

Although a Genesys application encountering a problem with licenses at runtime generates a Licensing Violation log message (a log event with ID #00-07100, it does not interrupt its service and it does not drop current interactions. However, the application may cease to process new interactions until the licensing violation is removed. A licensing violation may occur because:

  • The license has expired.
  • The number of licenses has decreased either in the license file or in the application's configuration.

License Failure Scenarios describes how you should determine and react to licensing violation.

This page was last edited on September 19, 2018, at 17:31.
Comments or questions about this documentation? Contact us for support!