<< Click to Display Table of Contents >> Navigation:  Modules > Asset Management > Software License Management > Licenses > Software License Allocation > Allocation Strategy

As software records received from the ASN processor or entered through the Manage Licenses menu option are consolidated, they are automatically allocated to authorizations in need of license coverage.  Such authorizations may have had their software discovered by an autodiscovery agent and added by the MIE (rogue detection), or a user may have received approval for a software request through the software request portal, or the authorization may have been added through the Bulk Authorize menu option.  In any case, authorizations are created in advance of having actually covered the authorization with sufficient license units.  The MIE allocates one or more specific instances of a software license to a specific authorization, then tracks that specific software instance through its entire life (as it moves from asset to asset, or person to person, through harvesting and re-deployment.)

The ASN processor assigns a pseudo serial number to each software line item that does not already contain a serial number.  The pseudo serial number is guaranteed to be unique.  Its primary purpose is to allow the ASN to be processed more than once without the risk of overstating software license counts.  When using the Manage Licenses menu option, each entry that is picked up and processed is assigned the same pseudo serial number that the ASN Processor would have assigned (using the same algorithm).  To the MIE, whether the license came in via the ASN Processor or via Managed Licenses, both look the same.

A software license line item may specify more than one copy that was purchased.  Initially the MIE will create a single tracking record for the license and keep a count of the number of licenses associated with that single record.  However, as licenses are required by the allocation logic, that single record will be broken into multiple records, and the licenses distributed across those multiple records, in order to best match the licenses needed by the individual authorization records.  The MIE attempts to keep a minimum number of records to account for licenses purchased, however it also attempts to maintain a detailed audit trail of to which authorization an individual license unit was allocated over time.

Software, unlike hardware, generally is not serialized by the publisher - so physically there is no way to identify a given copy of a software package uniquely from other copies.  The unique tracking of software copies is done virtually, therefore, by the MIE using the pseudo serial number.  

For software that is serialized by the publisher, as long as the unique serial numbers are reported via the ASN (and each software item is on a line by itself), the software's own serial number will be used.

The MIE follows a specific strategy when allocating licenses, as follows:

1.Only software licenses reported by the ASN or the Manage License screen will be allocated.  These are the ONLY ways software licenses are added.

2.The MIE will only accept licenses that match one of the currently defined applications in the MSL.

3.If a staged license record contains a negative price AND/OR a negative license count for a given software line item, the MIE will interpret that as a return (returned to the vendor for refund).  The MIE will remove from the current license pool the number of licenses specified.  Any unallocated licenses will be removed first.  If need be, the MIE will then start to de-allocate licenses in order to create enough to satisfy the return. If the number to return is greater than the number of currently owned licenses, then all owned licenses will be de-allocated and removed, however the MIE will not create a "negative" owned position, so any returns in excess of owned position will simply be ignored.

4.For each license processed, the price reported by the ASN is compared to the Market Price maintained in the MSL.  If the ASN price is less than the SLMASNPriceToMarketPriceTest setting maintained by the MIE (default is 60%) of the Market Price, the record is ignored, marked as an exception, and is not added to the license count.  This generally happens when media is purchased.

5.License records sent by the ASN processor will have their expiration date set if the corresponding MSL record has a defined License Length and/or License Expiration setting.  When a license reaches its expiration date, it is de-allocated from any authorization it is currently covering, leaving that authorization in need of another license.  The allocation engine will attempt to cover the now uncovered authorizations with still-valid licenses.  Expired licenses are archived for historical purposes.

6.License records for MSL items that have been marked for Manual Reconciliation will not be allocated by the allocation engine.  The license will be staged but not allocated.  Allocation must be done manually for such items.

7.During allocation the MIE will determine any authorizations that are in need of license coverage.  This includes authorizations that have some license coverage, but not enough licenses to completely cover the License Units Required for the authorization.  

8.The MIE will honor various constraints during allocation.  Note that some of this default behavior can be over-ridden via an allocation constraint template.  If the license record contains an Asset Number (as sent by the ASN Processor or entered as a constraint when staging the license in Manage Licenses, it means the license can only be used with a given asset.  The allocation engine will ensure the license is only allocated to the given asset.  Also, when an asset number constraint is set, it is honored for the life of the authorization.  The license will not be de-allocated and re-allocated elsewhere during its life.  After the asset is decommissioned, the license will remain unallocated indefinitely (or until the asset number constraint is lifted)

9.If the license record contains information for business unit, department, and/or cost center, the allocation engine will constrain allocating the license to only people (if the authorization is by named user) or assets (if the authorization is by device) that are assigned to the matching business unit, department, and/or cost center.  This only applies to the first allocation of the license unless over-ridden using an allocation constraint template.  If the authorization is subsequently harvested and the license freed, the license will then have its constraint lifted and will be available to be allocated to any business unit, department, and/or cost center.  This is to allow constraining licenses to people or devices owned by the same business entity that initially purchased the licenses (by constraining on first allocation), but to allow subsequent harvest credit (by lifting the constraint for future allocation).

10.If the license record contains geography information, the allocation engine will constrain allocation to only assets located in the matching geography.  This can be over-ridden via an allocation constraint template.  The allocation will honor this constraint for the life of the license and/or for as long as the constraint remains in force.  If a license constrained by geography is found to no longer match the geography of the asset to whose authorization it was assigned (meaning the asset has moved outside the constrained geography), the license will be de-allocated and a workflow will be triggered (if so configured).

11.If the MSL setting that governs the license record constrains allocation of the license to specific environments, and if that MSL entry is set to be authorized by device, and if there is an existing asset record in the system, then allocation will be constrained to only assets that match the defined environment(s).  This can be over-ridden via an allocation constraint template.  The allocation engine will honor this constraint for the life of the licenses or until the constraint it removed.  NOTE:  This constraint applies to all licenses assigned to the governing MSL entry.

12.If the MSL setting that governs the license record constrains allocation of the license to specific asset roles, and if that MSL entry is set to be authorized by device, and if there is an existing asset record in the system, then allocation will be constrained to only assets that match the defined role(s).  This can be over-ridden via an allocation constraint template.  The allocation engine will honor this constraint for the life of the licenses or until the constraint it removed.  NOTE:  This constraint applies to all licenses assigned to the governing MSL entry.

13.The allocation engine will honor license equivalents (also known as downgrade rights) as defined in the MSL entry that governs the available license.  Any available license will attempt to be allocated first to authorizations that match its version as a first priority.  Remaining licenses will then be used to cover any previous versions defined, in the MSL entry, as equivalents to the current license.