Page tree

DLM Licensing and High Availability

This document will describe a few possible setups to achieve higher availability of license features to requesting Uniface Applications.

Redundant License Servers

With three-server (or two-server) redundancy, if any two of the three (or one of the two) license servers are up and running, a “quorum” of servers is established, and the system is functional and serves its total complement of licenses. 
The situation in which the quorum is not established can only exists for clients that already have successfully checked-out licenses before and for the maximum amount of time defined in the license file (default duration for two server redundancy is 14 days).
Server redundancy is designed to provide hardware fail-over protection only and does not provide load-balancing. This is because with server redundancy, all servers will be addressed by the client.

Server Configurations

The setup of the two (or three) servers are identical as for standalone license servers. See DLMInstallGuide.pdf. No additional configuration is needed for the license service to work redundant.
Distinction between Redundant license servers and stand-alone license servers is done by the License file tag <redundant> </redundant>

 <redundant protected='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' >

Every license server in the redundant setup will have to use the same license file. So the license file needs to be copied to all machines in the cluster..

Client (application) Configuration

for all Uniface Applications that need licensed, every redundant license servers that are mentioned in the license file, need to be configured.
This means that in the used ASN file for the Uniface application, the $license_options parameter needs to contain the portnumbers and the servernames like this:


Which server name is marked as 'FirstRedundantServer' and 'SecondRedundantServer', is of no importance, as both servers will be addressed by the Uniface Application.

License-split Redundancy

As an alternative to server redundancy, license split redundancy is available when there is limited system administration available to monitor license servers, when load-balancing is required for applications located far apart (e.g., Oslo and Canbarra), or when two or more license servers are required.

With license-split redundancy, each one of the license servers serves a subset of the total licenses. As such, this method does not provide true redundancy in the way two- and three-server redundancy does.

Disadvantage of Split Redundancy will be, that when one server is unavailable, that subset of the total licenses that this server service, will not be available until that service is back on-line.

Server Configuration

The setup of the two (or more) servers are identical as for standalone license servers. See DLMInstallGuide.pdf.
No additional configuration is needed for the license service to work with split license files.
Every license server will have its own license file that will differs in the ID's bounding it to the system it runs on.
It is recommended, in case of split licenses, to have the same license features in all of the license files (this is not necessary for Server Features. see below notes).

Client (application) Configuration

For all Uniface Applications that are in need of redundancy, every license server can be addressed sequentially in the Applications ASN file like:


The Primary server, will be the first one to be contacted. If this server has the requested license feature to support, than the secondary server will not be contacted for this feature. Only when the primary server does not have the requested feature or has become unavailable, the secondary server will be contacted.

Which server will be designated as primary or secondary is up to the system administrator, as with changing primary and subsequent servers, some kind of load balancing can be achieved, where some clients will have server 1 as primary and others server 2 as primary.

Urouter/Userver configuration

to have high availability of licenses for the use by UServer functionality, it is recommended to have the UServer make use of the local license file instead of a license service.

Userver will make use of node-locked server features within the license file. A requirement is that the Server ID where the Userver is being started, must be known to the License Feature it requires.
As Node-locked (server) features are not in need of a license service, the Userver can use the license file directly when the license file is locally available.
Therefor the license file can just be copied to the server where the Userver is going to run on, even when other features are not valid for this system.

Userver Configuration

To configure the Userver to use a local license file, copy the license file to a location where the Userver can access if for reading.


Advantage for the Urouter / Userver is that is is not depending on the availability of a remote or local License Service. and its response times.

When the license server is not on the same server as the Urouter/Userver, the disadvantage will be, that you will have multiple places where the used license file is located.


  • The configurations for redundant servers and split service, do differ in how client communication will take place. In case of redundant license servers, both servers will be addressed by the client application, before a license feature will be approved for the use by the client.
    In case of license-split configuration, the first (primaryserver) will be contacted first. When a license feature can be approved, than the secondary server will NOT be contacted. Only when the primary server does not respond or does not have valid license, then the secondary server will be contacted.

  • It is recommended when having split license servers to have the same features in all license files. Although when the first mentioned server does not have a requested feature, the second server will be contacted for the rest of the license features that the application needs. However, when the second server does not have consecutive feature(s), but the first one does, it will NOT try the first server again, but feature checkout will fail.