FLEXnet Option Files Examples

What is FLEXnet publisher?

FLEXnet publisher (formerly known as FLEXlm) is a software license manager utilized by companies to manage software shared by different people on different workstations. With what are termed “floating licenses,” FLEXnet enables end users to draw and return software licenses from a license pool on a host server.

What is a FLEXnet option file?

An option file defines various operating parameters of the license manager.

Creating/Editing an option file

In order to create an option file, save a text document in the same folder as the license file. Next, the document the according to the name of the vendor, followed by the extension “.opt”

For example, an option file for Matlab will be named “mlm.opt”. Accordingly, option files for Autodesk and ESRI ArcGIS would be named “adskflex.opt” and “ARCGIS.opt,” respectively.

Allocating licenses to a specific user group

First, define a group with the keyword “GROUP,” followed by the name of the group, followed by the members of that group. Names are all case sensitive.

Example: A group called “Matlab_Users,” consisting of Billy, Jim, and Kim

GROUP Matlab_Users billy jim kim

Next, to select which licenses to allocate to that group, type the keyword “INCLUDE,” followed by the feature name, followed by the group name.

 Example: Allocating feature “Optimization Toolbox” to the group “Matlab_Users”

 INCLUDE MATLAB GROUP Matlab_Users

These two steps are combined:

GROUP Matlab_Users billy jim kim

INCLUDE MATLAB GROUP Matlab_Users

Limiting individuals or groups of users to a maximum number of licenses

In order to limit the usage of a feature by a group, first allocate the license to that group or individual as demonstrated above. Then, set a usage limit with the keyword “MAX,” followed by the name of the feature, followed by the group name.

Example: Limiting the max number of Autocad 2002 licenses used by group “Autocad_Users,” consisting of users Ronald and Lisa, to 7. (41100ACD_2002_OF is the name of the Autocad 2002 feature)

GROUP Autocad_Users ronald lisa

INCLUDE 41100ACD_2002_0F GROUP Autocad_Users

MAX 7 41100ACD_2002_0F GROUP Autocad_Users

Excluding access to specific features

Enter the keyword “EXCLUDE,” followed by the feature name, followed by group or individual being excluding.

Example: Excluding user Franklin from feature “Geosteering plug-in for Petrel 2013”

EXCLUDE OCEAN_SLB_SIM_GEOSTEERING franklin

Controlling license borrowing

To allow someone to borrow a feature, use keyword “BORROW,” followed by the name of the borrowed feature, followed by the user or group of users.

Example: Including users Bill and Sam in the list to borrow the feature Ansys Fluent

BORROW fluent bill sam

Alternately, to exclude someone from borrowing a feature, simply replace “BORROW” with “EXCLUDE_BORROW”

Example: Excluding users Bill and Sam from the list to borrow the feature Ansys Fluent

EXCLUDE_BORROW fluent bill sam

A “borrow lowwater” determines the number of licenses that must remain unused at any given time. Enter the keyword “BORROW_LOWWATER,” followed by the feature name, followed by the number of licenses that can’t be borrowed.

 Example: Setting a borrow lowwater for the feature autocad at 5

BORROW_LOWWATER autocad 5

To adjust how long a license feature can be borrowed, enter “MAX_BORROW_HOURS,” followed by the feature name, followed by the number of hours

Example: Maxing the number of hours a solidworks feature license can be borrowed for at 15 hours

MAX_BORROW_HOURS sldworks 15

Setting license timeout

FLEXlm license timeout is a feature that releases inactive licenses back to the license pool. Enter the keyword “TIMEOUT,” followed by name of the feature, followed by the time (in seconds) after which inactive licenses are released. To set a timeout for all features, simply enter “TIMEOUTALL,” followed by the time.

Example: Setting timeout for Matlab Database Toolbox for 14400 seconds (4 hours)

TIMEOUT Database_Toolbox 14400

Example: Setting a timeout for all licenses for 108000 (3 hours)

TIMEOUT  108000

The OpenLM Difference

OpenLM allows users to harness the full capability of option files using a unique graphical user interface. This interface dramatically simplifies the process of managing license parameters by allowing companies to use active directory groups to automatically generate option files.

Please follow and like us:

Application Note 1029: LDAP (Active Directory) Synchronization

General

The OpenLM Server is capable of synchronizing users and groups with an organization’s LDAP to combine license management, license statistics, and report extraction with other company information. LDAP synchronization provides automatic maintenance of Users’ and Groups’ data.

LDAP Synchronization holds many advantages, for different levels of decision makers in the organization. On an administrative and managerial standpoint, it can be applied for enforcing license usage permissions, implementing usage chargeback (usage billing), analysis of usage trends etc. Administrators may gain in automating FlexLM Option file management, thus streamlining FlexLM reporting. From the end-user point of view, this information may be applied to easily locate other users holding a required license.

The Groups synchronization functionality is part of the Users and Groups extension, and requires additional licensing.

Additional information

Please refer to the video tutorial section on the OpenLM site, for a demonstration of Active Directory synchronization.

Users and groups presentation

The Users and User groups which exist in the OpenLM Database are apparent in the EasyAdmin web application, in the Users and Groups windows respectively. Initially, upon installation of the OpenLM server, the Users and Groups windows are only populated by the logged user (e.g. ‘Orik’ – that’s me), the default ‘generaluser’ user, and the “OpenLM Users” default group.

The Active directory tab – Interfacing the LDAP

This tab is the OpenLM Server’s interface to LDAP (Active directory) synchronization. The 1st thing to do is to connect to the LDAP Database. Type in the LDAP server details:

  • Domain name: the IP Address of the server which is your organization’s domain controller (e.g: 102.101.100.106)

  • Username (e.g: administrator)

  • Password, and

  • LDAP server type: (e.g. “Active Directory”)

Click the ‘Check’ button, and receive an authentication status notification, as depicted below:

 

Organizations may have multiple domain controllers (for example, if different departments or subsidiary companies have their own servers for user authentication). In order to add a second server, select the row where the asterisk is shown above, and type in the data for the second server. In order to apply another synchronization rule to the same LDAP server, click the “Duplicate” button under the list of domain controllers.

Synchronizing Users

It is important to note that synchronizing to the LDAP is a tricky business. You may end up having taken in more users than you intended, and deleting users from the database is difficult. It is highly recommended to experiment on a separate database, NOT on the production database.

In order to synchronize user information:

  • Check the “Synchronize users” check-box. Other fields on the “Active directory” tab are activated.

  • Click the ‘Select’ button. The active directory browser opens.

  • Select a synchronization start node.In this example, We’ve selected an Organizational Unit (OU): OU_Test. Click ‘OK’ and the node path appears in the “Synchronization Start Node” text box. The LDAP would be synchronized from this node down.

 

  • Set the “Sync time interval” value. The value in this example states that the user details would be updated every 12 hours.
  • It is highly recommended to Check the “Sync only active users of licenses” in order to avoid adding users that do not actively use the application. New active users would be added to the list of users as they check out a license, and their LDAP details would be synchronized when the “Sync time interval” elapses.
  • Set the “Sync username attribute”.

    • “sAMAccountName” is good for Pre Windows server 2000 Active directory versions.

    • “userPrincipalName” is good for Post Windows server 2000 Active directory versions.

    • “cn”  should be used for any LDAP configuration other than “Active Directory”, i.e. “Novelle Directory” or “Apache DS” .

      The value of the selected field (sAMAccountName or userPrincipalName or cn) within the Active Directory would be applied as the user name recognized by OpenLM.

Synchronization of Groups

Check the “Synchronize groups” checkbox to enable a variety of options for associating users with groups in the OpenLM database, according to the data structure on the LDAP.

AD Groups:

This option goes through the list of users that populate the nodes beneath the selected node. The “AD Groups” selection should be used carefully, because it may introduce a large amount of undesired groups. This is because users who are members of groups within the selected node may also be members of groups from beyond that node, resulting in additional introduction of these external groups.

Attribute:

OpenLM groups may be created according to specific attributes their members may have. In order to do that, select the “Attribute” radio button, and pick up a suitable attribute from the adjacent drop-down list of attributes. Examples for attributes are: “Division”, “Employee ID”, “Initials” or “Cost center”. Type in a Regex expression that would articulate the required attribute.

Fixed:

This option enables the administrator to associate a particular group name to all users of a specific node within the AD tree. The ‘Fixed’ name typed in the textbox is the group name of the users that would consequently be synchronized in this method.

OUs (organizational units):

This option is in use by organizations that have an organizational hierarchy represented in the LDAP; for example departments nested inside divisions. By selecting the OU synchronization method:

  • Users would be introduced into groups in the OpenLM database. These groups would be named after the LDAP OUs under which the users have been created.

  • If the “Add full hierarchy” checkbox is ticked, the entire OU hierarchy tree descending from the start node would be introduced as groups in the OpenLM database. OUs in which no users have been defined in the LDAP, would be presented in OpenLM as empty groups.

  • If the “Add full hierarchy” checkbox is not ticked, OpenLM would flatly create groups named after the LDAP OUs, and populate these groups by the users which have been defined under these OUs. No empty groups would be created.

Case study

In order to demonstrate the different group synchronization methods, I have created the following OU structure, and enabled all users. Note that Users U_A1 & U_AB2 are members of more than one group:

Case 1: Synchronize users only

Procedure: OU_AB was selected as the start node.

Outcome: All Users were synchronized. No Groups or OUs synchronized.

Case 2: Synchronize AD Groups (1)

Procedure: OU_AB was selected as the start node.

Outcome: All groups and users beneath OU_AB were synchronized. The Hierarchical tree was not preserved.

Case 3: Synchronize AD Groups (2)

Procedure: OU_B was selected as the start node.

Outcome:

  • Users B1 & AB2 have been synchronized.
  • Group B1 was synchronized.
  • Group A1 was synchronized, with only user AB2.

Case 4: Synchronize AD Groups (3)

Procedure: OU_A was selected as the start node.

Outcome: Mirror image of the previous case:

  • Users A1, A2, A3 & AB2 were synchronized.
  • Groups  A1, A2, A3 & B1 were synchronized. Group B1 only contains user AB2.

Case 5: Fixed

Procedure: Start node = OU_A. The “Fixed” name was named “The_A_Team”.

Outcome: All of OU_A’s users were gathered in “The_A_Team” group.

Case 6: Attribute

Reminder: Users A1 & B1 are the only users to have been defined owning “division” attributes with the value “my_division” (See LDAP diagram).

Procedure: OU_AB was selected as the start node. The “Attribute” synchronization method was chosen. The ‘division’ attribute with the value “my_division” was configured in the Active directory configuration form.

Outcome: All Users in OU_AB were synchronized. Users A1 & B1 were gathered in the “my_division” group.

Case 7: OU

Procedure: OU_AB was selected as the start node. “Add Full Hierarchy” was not checked.

Reminder: Users  AB1 & B1 were created under the OU_AB Operational Unit. All other users, i.e. A1, A2, A3, AB2 were created under OU_A.

Outcome: All users under OU_AB were synchronized. OpenLM has flatly created groups named OU_AB, and OU_A. Each of these two groups contain the users which have been created under the respective LDAP’s OUs:

  • Group “OU_AB” contains the users AB1 & B1 (see image below).
  • Group “OU_A” contains all other users, i.e. A1, A2, A3, AB2.

Case 8: OU (2)

Procedure: OU_AB was selected as the start node. “Add Full Hierarchy” was checked.

Outcome: This time the OU hierarchy was preserved, so OU_A and OU_B appear under OU_AB. The users are again grouped according to the position in which they were created:

  • Group “OU_AB” contains the users AB1 & B1.
  • Group “OU_A” contains all other users, i.e. A1, A2, A3, AB2 (see image below).
  • Group “OU_B” is empty.

Please follow and like us: