Skip to main content
Matrix42 Self-Service Help Center

How to reconcile the status of license compliance

Introduction

Once the decision has been made to actively manage license compliance via the Matrix42 License Management and this tool has been installed accordingly, a consistent procedure should be followed. Before you can maintain the compliance status continuously on the basis of the following standard procedure, the respective software products must be reconciled regarding license compliance the first time. This process is called "initial reconciliation of compliance".

Illustration of initial reconciliation process

As a best practice approach, it is recommended to carry out this reconciliation per publisher. This is to ensure transparency of the license terms and an exact and correct calculation of the required licenses. This provides a stable foundation for continuous updates during operational license management.

The team performing this comparison should include all relevant roles and responsibilities, including license management program members and the software publisher's lifecycle manager.

The license management program includes the following members:

  • SAM program manager or representative
  • Change manager or representative
  • Matrix42 tool specialist

For the publisher's software lifecycle:

  • License specialist
  • Owner/acquirer of the license inventory
  • Responsible owner for software deployments

This team works together within the framework of the overall comparison of license compliance for the respective software publisher. If the publisher's software portfolio is quite comprehensive or heterogeneous, it may make sense to divide the comparison into several steps, e. g. first of all the desktop applications, then the server software, etc.

Volume License Agreements

First of all, the opening balance sheet requires the team to collect and review all available information about existing volume licensing agreements (framework agreements) and licenses acquired in the past; if licenses have been ordered locally from different locations or organizational units, this may be a rather complex task.

Accurate review and a good understanding of each document in the compiled documentation is extremely important. Then, both the framework agreements and the license purchases are recorded in Matrix42 License Management and imported accordingly. In addition, appropriate references or digital copies must be attached to each individual license data set. If possible, no records should be added that could not be verified or understood correctly.

It is also important to understand possible alternative licensing options, the composition of suites and bundles as well as consolidation rights (e. g. second copy rights), downgrade options and the adaptation of the respective software products in Matrix42 License Management.

License Models

A license model can be understood as the rules that correspond with how a software manufacturer grants the right to use of one or more copies of a software product. It essentially provides the rule how the license need to be assigned and the metric that is used to calculate the required quantity of licenses for a single deployment.

For reconciliation of compliance it is important to understand which license models are eligible for licensing of a particular software product. This may be defined in publisher's product terms and be influenced by your current and previous volume license agreements. 

License Intelligence Service provides numerous license models that you may use. However, feel free to create your own license models. License models have essentially four settings that should be considered:

  1. Name: The name of the license model that is used for entitlements is displayed in the software compliance report. Therefore, if your publisher is using a license model or metric with a specific name, you may create a license model with the same name. This can improve comprehensibility of your reports.
  2. License Assignment: This setting defines the type of consumer to which the corresponding license should be assigned (Entitlement Consumer):
  • Device:  Choose this option when license needs to be assigned to a physical device.
  • Device with Second Copy: Choose this option when licensing is "per physical device", but a second copy on portable devices is allowed.
  • Named User: Choose this option when licensing is per specific user.
  • Operating System Environment: Select this option if you need to license per computing environment (regardless whether it is a physical or virtual system).
  • None: Use this option if there is no specific assignment rule setup by the publisher, i.e. could be a user or a  computing device
  1. Effectiveness: Select this checkbox if all automatically created license requirements are valid for license entitlement and compliance. This is applicable for most cases. However, the system can also create license requirements that do not need entitlement by a license. Deselect this checkbox if such requirements however should be created. This option might be useful for keeping track of deployments (e.g., when license metric is based on parameters that cannot be counted, for instance concurrent use). Such ineffective license requirements will have a quantity equal to zero and thus do not require entitlement with available licenses.
  2. Calculate number of required usage rights using the following expression: This setting defines either a static number or a formular expression (in ASQL) that is evaluated by the system during data processing to determine the number of required licenses.

Select or create the license models you need for a particular software product and add them to the list of relevant license models there. Also set the default license model for the software product which will be used by the system for any automatically created license requirement. 

Purchased Licenses

To create and update the license balance, Matrix42 License Management should know what licenses exist in your company. You can either create licenses and enter the respective information yourself or import them to the system.

When you save or import a license record, the system will validate it. It means that the system checks information that was provided to ensure a minimum level of data consistency. For example, it is necessary to provide purchase information as a proof that the license was legally acquired. If some essential information is missing, the system sets the license status to Invalid and specifies the reasons why validation failed.

However you should ensure that you provide all necessary information you need later in a license review to proof that you own the license (e.g. legal invoice). Make sure you don't import license records you cannot present the evidence of ownership.

At the end you should conduct a final review of all records in your license inventory that you have imported or manually created for the current scope. Make sure you setup your upgrade and maintenance chains appropriately. This includes correct license models (i.e. metric). Based on changes in licensing terms by the respective vendor (e.g. renewals of volume license agreements) you may have to convert your licenses to different metric (e.g. from CPU to Core). 

Software Deployments

All your software deployments should be entitled by valid licenses. Accordingly, it is important to understand how the respective software is currently deployed. This includes answers to the following possible questions:

  • Are there local installations on computers?
  • Are there hosted copies that are accessed over the network (e.g., XenApp, Terminal Services)?
  • Are there any other provisioning technologies (e.g., ThinApp, App-V)?
  • Does the software provide a Web browser interface that should be entitled somehow?
  • Are there any deployments for specific purposes (e.g., Test, Training) that need special consideration?
  • Is technical software recognition complete and accurate?

We recommend that you establish a way to automatically derive license requirements from appropriate data sources. There are several ways to let the system automatically create and maintain license requirements:

  • Installations: By using assigned fingerprints from local installations.
  • Group Memberships: By using assigned groups (e.g., imported from Active Directory) with respective members.
  • Remote Use Tracking: By using actual remote execution of assigned applications or remote access to application hosts that are equipped with assigned software products.
  • Collateral Requirements: By using license requirements for other assigned software products.
  • Catalog Services: By using approved requests for assigned services.

You may use several options at the same time. The system will ensure that there is still only one license requirement record per consumer.

Example:

  • Application X is locally installed on many computers (Installation/Fingerprint)
  • Application X is also deployed on a Remote Desktop (Remote Use Tracking/Executable)

At this point it might be also appropriate to verify both authorization and actual need for existing deployments. Contact end users or respective managers to get either confirmation for user's demand or approval to remove the deployment. This activity will not only help you reduce financial risks from being non-compliant or saving costs in the future, but also decorate your license management program with first accomplishments.

The fingerprints are imported from a connected inventory management system. Matrix42 License Intelligence Service (LIS) helps you assigning fingerprints to a software product (software recognition) if an application is relevant for licensing. Applications that do not require a commercial license are not assigned; instead, they are marked as "ignored as irrelevant". Also, if the fingerprint of an application cannot be interpreted, it is ignored as "unknown". 

We recommend that you review all fingerprints that belong to the applications of the software product you are currently reconciling and adjust any automatic classification if appropriate. Remember, you may classify any fingerprint yourself at any time. The system will maintain your choice and not override.

License Requirements

Introduction

License Requirements are records that document the fact that a relevant Consumer requires a certain amount of valid licenses for a Software Product - according to the License Model - to be entitled for the availability or usage of an application.

  1. Consumer: Usually a physical device, an operating system environment (OSE) or a named user that is the target of the license assignment. This license assignment must correspond with the License Assignment setting of the relevant license model. In addition, the status of the corresponding consumer must be relevant for licensing. Users or devices that don't exist anymore and their records are kept only for documental purpose (inactive status) do not require a license.

  2. Software Product: License requirements are associated with a Software Product record which represents the software title – including specific edition and version – that the publisher defines by the licensing terms and software usage rights. You may understand Software Products as single positions in your license position report (license balance).

  3. License Model: License models define basically two essential parameters: 

  • Which entity holds the license that is required? This is called license assignment. It could be a named user, a named device or a named operating system environment. This setting influences the Consumer of any created license requirement. See details below in chapter "License Assignment".

  • How many usage rights (i.e. licenses) are required, based on the metric? This setting influences the Quantity of any created license requirement.  For instance, if the metric is "per Core" and the assignee (consumer) of the license is a physical computer having 4 Quad-Core CPU, 14 usage rights are required (4 CPU * 4 Cores each).

The combination of a consumer and a software product is the unique key across all existing license requirements. That means that it is not possible to have multiple records for the same consumer and same software product. This avoids double counting and complies with the publisher’s licensing terms.

Please note that automatic calculation of usage rights require that corresponding data is available in the database. There are some metrics that do not support automatic calculation out-of-the-box. For instance: Concurrent user. This is because this information is not available in the system.  In case your software product is licensed by such a metric, you have two choices:

  • Import this information from a source that provides this data points and store them in the right context. Create a license model that uses this stored data for automatic calculation.
  • Define the quantity of the license requirement manually.

Life Cycle

License requirements are usually created and deleted automatically by the system for relevant consumers based on relevant scenarios. Relevant scenarios are displayed on the Foundations page of the License Requirement properties dialog. Every license requirement that is managed automatically by the system needs to have at least one foundation. If the last foundation record is removed, the license requirement will be deleted as well.

The relevance of a consumer is based on the status of the respective record:

Consumer (Configuration Item) Relevance Definition
User (Person) Status is Active
Device (Asset) The current asset status value of the device is included in the Asset Status Values Relevant for License Compliance drop-down list in the global system settings (Administration > Global System Settings > Assets) and – for devices of the Server computer role – the value of the Power Status field is Powered On.

The relevance of a scenario is based on meeting the conditions for relevant configurations defined for the corresponding software product:

Scenario/Foundation Condition Configuration
Local Installation Application is installed Fingerprint Assignment
Remote Usage Remote usage exists Executable Assignment
Group Membership Consumer is a member of group Group Assignment
Collateral Requirement Matching license requirement exists Dependency Rule
Service Booking Approved service booking exists Service Assignment

It is important to understand the system behavior if the consumer, or the configuration or the condition of a license requirement becomes irrelevant.

Irrelevance of

Examples

System Behavior

Consumer

  • Status of an asset changes to Disposed because the device has been returned to supplier for recycling.
  • Status of a person changes to Inactive because the user has left the organization.

Foundation record is immediately removed since the minimum entitlement period does not apply to irrelevant consumers.

Configuration

  • Fingerprint, AD group, executable, service or dependency rule has been deleted or is not assigned to the software product anymore.

Foundation record is immediately removed since the minimum entitlement period does not apply to irrelevant scenarios.

Condition

  • Local installation was removed.
  • Remote usage record does not exist anymore.
  • Consumer is not a member of an AD group anymore.
  • Service booking is not approved anymore or has been deleted.
  • Dependent license requirement does not exist anymore.

Foundation record is removed only when the minimum entitlement period has elapsed.

The minimum entitlement period is the time that a consumer needs to hold the license before it returns to the license pool. This is a licensing term used by some vendors, e.g., Microsoft, to prevent abusive use, such as floating entitlements for different devices or users. The minimum entitlement period is defined for each software product.

Confirmation

It is a basic design concept that license requirements that are created automatically by the system should be confirmed by a responsible user. There is no need to confirm license requirements that have been created manually.

Only confirmed license requirements are effective in terms of license compliance, consolidation, and entitlement.

There are two principal reasons for this procedure:

  • Being informed about new license requirements helps you to review authorization of the corresponding deployment just in time and manage possible unauthorized occurrences.
  • Confirmation prior to entitlement helps you to decide about eligible license model in cases of several licensing options (e.g., Server + CAL vs. CPU or Core).

You may automate the confirmation step per software product if both reasons above do not apply. 

Set confirmation mode to "manual" if you assign a software product to a catalog service. Every approved catalog request will result in an automatic confirmation while unapproved (and possibly unauthorized) deployments will keep corresponding license requirement unconfirmed. This mechanism will help you to identify unauthorized deployments and control your software request and approval process.

License Assignment

Overview

For all automatically managed license requirements, the system compares the License Assignment setting of a license model with the technical consumer that is referred by the license requirement based on the source (Foundation). If there is a mismatch, the system ensures that there is a license requirement for an eligible consumer. 

License Assignment
defined in License Model

Consumer type based on source of a license requirement

Consumer type for effective license entitlement

Device / Device with Second Copy

Physical Computer

Physical Computer

Virtual Computer

Relevant Host Computers

Mobile Device

Mobile Device

Person

Physical Computers and Mobile Devices of Person

Named User

Physical Computer

Principal User of Computer

Virtual Computer

Principal User of Computer

Mobile Device

Principal User of Device

Person

Person

Operating System Environment (Computer)

Physical Computer

Physical Computer

Virtual Computer

Virtual Computer

Mobile Device

Mobile Device

Person

Computers and Mobile Devices of Person

If a license requirement is created manually or the Manual Definition setting is enabled, the system will not check the technical consumer of such a license requirement. So even if the license requirement’s consumer is different from the one defined in the License Assignment setting of the license model, no further license assignment is made. Instead, this license requirement will be valid and can be entitled with a license that has the same license model.

Scenario 1. Licensing per Device

  • The system creates a license requirement with a virtual machine that is specified as a consumer.
  • License consumption of the license model is Device.

The system will create a secondary license requirement for each of the current and previous hosts of the virtual machine. The primary license requirement will be automatically consolidated with the secondary requirement(s) and referenced on the Foundations dialog page of the secondary requirement(s).

Note: License requirements for hosts will be based on the information that is displayed on the Virtualization dialog page of the corresponding virtual machine. The system will create a requirement for a host only if Minimum Period of Entitlement of the relevant software has not yet elapsed since the virtual machine had been last hosted on this device.

License Compliance