Setting

Definition

Publisher's SKU

This value, if available, can be used to match incoming Advanced Shipping Notice (ASN) records via the ASN processor.  When the Publisher's SKU is available, the ASN processor will match directly on incoming ASN information, without the need to create User Defined Filters (UDFs).

Publisher, Title, Version

These settings define the official way the MSL item is spelled.  

Class, Subclass

These settings are optional and can be used to group MSL items together.

Family

This setting allows several MSL titles to be combine, for the purposes primarily of compliance reporting, into one family.  Generally families are chosen along compliance reporting lines - such as Adobe Acrobat - where several versions all participate in rolling-up to the actual compliance position.

Order

This is the hierarchy order of this title within the family.  When the allocation is honoring license equivalents, it will process in this order.  1 is the top of the hierarchy.

Governing license contract

The current contract that governs licensing of this MSL title.

Entitlements for this title

Any specific entitlements, as afforded by either the maintenance or license contracts (or other contracts), that are in force for this title.  These entitlements are available for ALL active authorizations.

Optional entitlements for this title

Any entitlements that are not automatically available for all active authorizations, yet can be optionally selected and assigned to specific authorizations.  The Software Request Portal uses this setting to know which entitlements to optionally offer for each MSL title.

Governing maintenance contract

The current contract that governs software maintenance for this MSL title.

License Type

The type of license.

Request Portal Custom Message (optional)

This text value will be displayed as an alert message in the Software Request Portal when this Software Title is added to the Request Manifest. If you leave this field blank, no message is displayed.

Assign authorizations

Defines how the MSL title will be authorized.  

Assign to Device means the authorization will be tied to the physical asset itself.  This type of authorization is generally used for workstation or by-CPU type of licenses.

Assign to Named User means the authorization will be tied to a person.  This type of authorization is generally used for by-Named User type of licenses where the software can be auto-discovered on the user's workstation(s).

Assign to Contact List means the authorization will be tied to a contact, or assignee, list or group.  Such a group is nothing more than a list of people.  The authorization is granted at the group level, and individual license units required to cover the authorization are counted as the number of people assigned to the group.  This type of authorization is generally used for applications that are licensed by named user, and there are a large enough number of users to warrant managing the authorization as a group.

NOTE - the Assign Authorizations setting will be available for change up until the first authorization is granted.  Once an authorization has been granted, this setting will become read-only.  If you wish to change how the title is authorized, at that  point you must set up a new MSL entry for this title and select the new authorization method.  You will then have two MSL entries for the same title, some having been authorized via the old method.  Also, ANY ROGUE AUTHORIZATIONS WILL BE PERFORMED USING THE NEW METHOD.  DEPENDING ON AUTODISCOVERY, THIS MAY RESULT IN DUPLICATE AUTHORIZATIONS, WHICH MAY RESULT IN OVERSTATEMENT OF DEPLOYED COUNTS.

This title is part of this suite ...

NOTE:  This setting applies only to usage monitoring using the WDA.  This setting has no impact on license calculations.

If specified, the title is a sub-component of a suite.  Usually the suite level is carried as the title that is officially on the MSL.  Sub-components, if carried in the list of MSL titles, are usually there to allow usage monitoring and are usually marked as not officially on the MSL.  If a suite is assigned, it will change how usage monitoring acts.

License Equivalents (Other MSL titles that can be covered by licenses from this title)

This setting allows you to specify other MSL entries that can be covered by licenses from this entry.  As an example, your license for Microsoft Office 2003 may allow you to cover an Office 2000 install.  Office 2000 would be set up as also being covered by Office 2003 licenses in that case, making Office 2003 a license equivalent of Office 2000.  License equivalency only works in one direction.  MSL entries specified as being covered by this entry can use licenses from this entry to cover installs, however the reverse is not true.

Manage downgrade rights locally

If checked, and if this title has been linked to a Wiki master title, then any license equivalents defined in the wiki master will be ignored, and must be managed locally.  If not checked, then any license equivalents defined for the wiki master title that are not currently defined for the local title will be copied to the local title when the next Consolidate runs.

Harvest any down-bound equivalents

Checking this box causes the automatic harvesting of any down-bound equivalents that may be authorized on the same device.  This setting is usually used to ensure authorizations for previous versions are automatically harvested.  If checked, the authorizations for each device will be checked and if this MSL title and any one of the titles defined in the License Equivalents box are found to be on the same device, the License Equivalents will be harvested.

Item is allowed to be un-installed

If checked, when harvested, the MSL item will be scheduled for automatic de-installation through the Application Push Scheduler (APS).

Item is officially on the MSL

If not checked, the item will not appear on the View MSL applications catch point screen, even if a copy is authorized to be on the asset.  Also, if not checked, the Move MSL applications catch point screen will not move this item from one asset to another.  Furthermore, if not checked, this item will not participate in compliance reporting.  Otherwise, the item will behave as any other MSL application and it will observe all other settings (charges will apply for rogue discovery, for instance.)

Watch usage on this MSL item

If checked, usage data will be recorded to the Authorized Software table for each asset that is authorized to have this MSL item.  Limited usage data is available through WTR and the ActiveX component that accompanies the catch point screens.  Full usage data requires the Workstation Data Assistant to be installed on each monitored machine.

Watch compliance on this title

If checked, the title will be contained on compliance reporting.

Item is allowed to be requested (through request portal)

If checked, the item will display as available for request when using the Software Request Portal.  Generally, an older version that is to be sunset will not be checked once the newer version has been added to the MSL.

Item requires approval for installation.

If checked, when requested for installation through the Software Request Portal, the request will first be routed to the department/cost center/organizational approver (based on the Workflow Management approver's matrix) for approval.  If approved, the MSL item will be added to the authorized software table for the requested asset number.  If not checked, the MSL item will be immediately approved upon finalizing a request through the Software Request Portal.

Harvesting is allowed

If checked, the MSL item will be presented for harvest on all harvest catch point screens (assuming the MSL item is currently authorized to be on the asset)

Manually Reconcile

If checked the MSL item will not participate in the MIE's license allocation engine.

Workflow to fire upon successful authorization

If defined, this workflow will be fired each time this title is authorized or checked for authorization.

Workflow to fire upon successful harvest

If defined, this workflow will be fired each time this title is harvested.

Authorization Analyzer Rule

If the title is subject to complex licensing rules that are primarily linked to the parameters of the hardware on which it is installed (such as number of processors, number of cores, environment, virtualization, etc), then it may be set to have its authorizations analyzed periodically by the MIE's Authorization Analyzer (AA).  (Also known as the Data Center License Analyzer - DCLA)  The AA uses a rules-based engine to calculate the number of licenses required to cover each authorization, and automatically updates that count.  If this title qualifies for use with the Authorization Analyzer, and a rule exists to handle the licensing rules for this title, select that rule here.

NOTE:  Some rules are developed and maintained by ESI.  Those rules start with "(ESI Master)-"  You may use any of the appropriate ESI Master rules, however be aware that ESI may make updates to these rules at any time and those updates may impact your deployed position counts. Also note that ESI makes no warranty, express or implied, as to the accuracy of the rule or appropriateness for your environment.

Use this DCLA rule instead

If the MSL title has been tied to the Wiki Master (and therefore automatically inherits the rule assigned to the Wiki Master title) and you wish to assign a local rule, this is the setting to use.  Select the local rule you wish to assign and it will override the use of the primary rule.

Title requires license keys

Check if the title requires license keys to work (publisher issues an individual license key to enable each license).  If checked, the title will not participate in license optimization - once a license has been allocated to an authorization it will stay allocated until harvested or until the license expires.  Also, if checked and if a workflow is defined, the MIE will create a workflow thread each time a license for this title is allocated or de-allocated.  The workflow can be designed to do practically anything, however the primary anticipated function would be to notify the end user of the key being assigned and to give instructions on how to install the key in order for their new software to function.

Workflow to use to notify end users of key assignment

Defines the workflow to be used to notify end users of key assignments and/or revocations.  A thread for this workflow will be created for each allocation/de-allocation of any license belonging to this title.

NOTE:  Each attempt at creating a thread is logged to the License Key log.  In some instances a thread will not be created (such as will be the case when no license key value is contained in the license record, or no email address could be determined for the end user).  Check the License Key log (available on the dashboard) and/or the error log and/or the Consolidate job log for details on why a thread may not have been created.

Title requires an owner

If checked, the MSL item requires an Application Owner to periodically supply authorized (deployed) position information. Application Owners are generally required for complex licensing schemes where the current authorized position cannot be determined through completely automated means.

The MIE will use the Workflow engine to periodically send an Excel spreadsheet to Application Owners for them to complete and return.

Workflow for managing owners

Defines the workflow to be used to send/receive the Excel spreadsheet to/from Application Owners.

Excel template to send to owners

Defines the Excel Template to be used to create the Excel spreadsheet that will be sent to Application Owners via the defined workflow.

License Length, License Expiration

License Length defines the length of time, in months, the license is valid.  The MIE will calculate an expiration date for each license received from an ASN.  The expiration date will be based on either the date the MIE staging record was created (if no purchase date was defined), or the purchase date.  The expiration will be set the number of months defined by License Length into the future.  If License Length is set to 0, it will be ignored.

IMPORTANT - when using the License Length setting, it is important to make sure the purchase date is supplied with the ASN feed.  Otherwise, it is possible for the expiration date to be set incorrectly, which may result in a compliance issue.  As an example, if a historical ASN is being loaded (an ASN that specifies historical purchasing activity) and no purchase date is supplied, the MIE will use the date created of the staging record, and set a date into the future for expiration.  However, if the actual licenses being loaded were purchased far enough in the past, it is entirely possible the licenses have already expired.

License Expiration sets a fixed date when all licenses will expire.  Only licenses received by ASN after the License Expiration date has been set will be set to expire.  Any licenses received by ASN prior to setting License Expiration will continue to exist with no expiration.  If License Expiration is left blank, it will be ignored.

If a license expiration is set, it will be checked each time Consolidate runs.  If the license expires, it will simply be deallocated from any existing install it may be covering, leaving the install in need of new license coverage.  New licenses must be loaded via the ASN to cover the installs that the expired licenses used to cover.

Setting License Length to 0 and leaving License Expiration blank will cause all licenses added by ASN to have no expiration.

Constrain license allocation to assets in these environments

This setting, if populated, will cause the license allocation engine to allocate licenses of this title to assets that match one of the environments specified.  For example, if you constrain allocation to only assets in the DEV and DR environments, then licenses will be allocated only to assets assigned to those environments.  Also, if an asset has an authorization that is covered by a license of this title, and moves to a different environment (one that does not match this setting), any licenses allocated will be de-allocated.  This setting only applies to titles that are authorized by device, is disabled if left blank.

Constrain license allocation to assets in these roles

This setting, if populated, will cause the license allocation engine to allocate licenses of this title to assets that match one of the roles specified.  For example, if you constrain allocation to only assets in the EMAIL and WEBSERVER roles, then licenses will be allocated only to assets assigned to those roles.  Also, if an asset has an authorization that is covered by a license of this title, and moves to a different role (one that does not match this setting), any licenses allocated will be de-allocated.  This setting only applies to titles that are authorized by device, and is disabled if left blank.

Minimum time license must stay allocated

The number of days that, once allocated to cover an authorization, the license must remain allocated before it can be used again to cover a different authorization.  This is determined by the various license rights.  Set to 0 to indicate there is no minimum allocation time required.

NOTE:  As licenses are allocated the date of last allocation is set.  If a license is de-allocated prior to this setting expiring since the last allocation, the license will still show in the owned count, however it will be left unallocated in the pool of licenses (as an unallocated license).  Once the time has expired, the license will be made available for automated allocation.

Workflow to fire when asset geography differs from authorized geography

If this MSL title is authorized by asset, and if the geography of the asset now differs from the geography that was assigned to the authorization for this MSL title on that asset, then this workflow will be fired in response.  The workflow can be designed to notify an individual of a change in geography, or it could be designed to send a notification directly to the publisher (in accordance with the publisher's terms.  Note that when the geography differs, in addition to this workflow being fired (if defined), the geography of the authorization will be updated to agree with the geography of the asset.

Market Price

This setting represents the current market price for a single license.

Price to Charge

This setting represents the price a business unit will be charged when requesting this MSL item through the Software Request Portal, or when this MSL item is auto-discovered on a given asset (rogue).

Family for mutually exclusive rogue authorization titles

If a family name is selected, and that same family name is also assigned to one or more other MSL titles, then all titles that have been so grouped are now considered mutually exclusive for the purposes of rogue authorization.  When a title in the group is about to be rogue authorized, the MIE will check to see if any other authorizations exist for the other titles in the group.  If at least one other authorization exists for the group, the current title will not be rogue authorized.  This setting is useful for grouping titles such as SQL Server by Core and SQL Server by Server/CAL, which should be mutually exclusive on the same machine.  If recognition training had been set to recognize SQL Server by Core (as an example), then by assigning both SQL Server titles to the same mutually exclusive family, this prevents the MIE from automatically creating a rogue authorization for SQL Server Core when SQL Server Server/CAL has already been authorized for that machine (as an example).  This setting honors the Wiki Master (meaning that if the customer has opted into the Wiki Master, titles that are linked to Wiki Master titles will inherit mutually exclusive settings of the Wiki Master.

Automatically authorize for assets in this status

If a status value is entered, then each time Consolidate runs it checks all assets currently in the status defined to see if each has been authorized for this MSL item or any of its upbound equivalents.  If the asset has not been authorized previously, Consolidate will automatically authorize it and attempt to cover it with a license.  Consolidate adds new assets and processes all new status values prior to checking for auto-authorization, so anything added/changed during the current Consolidate run will be picked up by auto-authorization.

Harvest existing down-bound equivalents when auto-authorizing based on status

If this box is checked and this MSL title is authorized by status to be on a given computer, then the authorizations already on that computer are checked and any that are active and have been defined as a down-bound equivalent to this title will be harvested.  For example, if Acrobat 10 is authorized by status and Acrobat 9 is found to already be authorized, and if Acrobat 9 has been defined as a down-bound equivalent to Acrobat 10, then the authorization for Acrobat 9 will be harvested.

NOTE:  Harvesting is done by placing a record in the staging table for Consolidate to process.  It may not take affect until the next Consolidate cycle.

Constrain status-based authorization to these asset types

If one or more values are selected, then any items that are auto-authorized will only apply to assets of the types defined in this setting.  If this setting is left blank, then the asset types to which auto-authorization will be constrained are defined by the global setting SLMSWBearingAssetTypes.  If that setting is blank, then all asset types will be considered.

When auto-authorizing, set license units required to this value

When the MIE automatically authorizes this title, the value entered in this setting will be used to set the license units required value for the authorization.  This value tells the MIE's license allocation engine how many license units are needed to cover the authorization.  You may enter a general tag in this field to cause the value to be determined when the authorization is granted.  For instance, you might use the {%LOOKUP%} tag to set the license units required equal to the number of processors or cores in the asset on which this title has been installed.  If you use a tag, you must make sure it evaluates to a number.  If it doesn't, the value "1" will be used.

Note:  This setting is ignored for titles that are authorized by group as the number of members of the group is used as the required license unit count.  It is also ignored by the Gen II Software Request Portal (the number of units required is specified when ordering through the portal).  The setting is also ignored by any catch point that solicits the number of units required to cover the authorization.  It is honored by rogue, bulk, CI, and status authorizations.

Credit/Debit Overrides

(see Business Unit Overrides)

Image name

This is required for usage monitoring.  WTR, ActiveX, and Workstation Data Assistant all monitor for usage by checking the asset's current task list for any task with this name. Watch for Usage must also be checked for usage monitoring to take place for this MSL item.  

Limitations:

1.  Different versions of the same application often use the same image name.  Therefore, when a machine has more than one version installed, the usage monitor may not differentiate one version from the other (since both use the same image name).  This will result in usage being reported against both versions of the MSL application, even if only one is being used.  The recommendation is to choose which version to monitor, and turn off usage monitoring on other versions.

2.  Some MSL items may be tracking harvesting and licensing at a "suite" level.  A good example is Microsoft Office.  A suite is comprised of several different applications.  In order to monitor usage of one or more of the applications in the suite, therefore, the applications to be monitored must also be established as MSL items, with Item is Officially on the MSL left unchecked and Watch Usage checked.  This will allow usage to be monitored without including the monitored items within the official MSL.

Debits (charges) start on this date for rogues for this MSL application

If a date is placed in this field, then charging for discovery of rogue software installations will begin on this date.  Grace (no charge assessed) will be extended to all rogue software discovered and authorized before this date plus the SLMGraceFromMSLStartCharging setting.  If the SLMGraceFromMSLStartCharging setting is set to a negative number, or if this setting is blank, this setting will be ignored.  There are two windows that will be used to establish grace - this window is one of them.  If this window is ignored, it is still possible for grace to be extended if the other window is satisfied.  See the SLMGraceFromAssetCreation setting.

Automated Software Delivery and Installation

These settings are used to define the specific software distribution package/job to use when scheduling this MSL item for installation (after request and approval).  If these settings are not present, the end user will generally be instructed to call the Service Desk for assistance in getting their newly approved MSL item installed.

Software package delivery method

Defines how software install, and de-install packages are to be delivered.

Client task to use to install package (Workstation Data Assistant Only)

Defines the client task that will be used to deliver the software.

Delivery Order

This setting defines the order in which requested, and approved, MSL applications will be sent to the electronic software distribution (ESD) system.  The lower numbered delivery orders will be sent before the higher numbered delivery orders.  If left blank, the applications will be sent in no particular order.  This only applies when a request includes more than one MSL application to be sent via ESD.  This setting only governs how APS will send the applications to the ESD system.  The ESD system may, in turn, ignore the order in which it received requests to distribute software and choose its own ordering.

Automated Software De-installation

These settings are similar to the installation settings but are for automated removal of software.  If not present, harvesting will still be allowed however no removal of the harvested software will be attempted.

Client task to use to de-install package (Workstation Data Assistant only)

Defines the client task that will be used to deliver the de-install package, used to remove the software after an end-user or technician harvest event.

Statistics

These are read-only counters that are updated each time a Consolidation is run.