De-Allocation pre-processor

The de-allocation pre-processor will only be run when Consolidate has no pending items in the staging table to process (including exceptions) or when the license optimizer has been forced to run (see ConsLicenseOptimizeRun in Consolidation Settings).  It performs several tasks as follows:

1.Attempt to nullify any returns that are waiting using upbound equivalents.  A MSL title may have a count of licenses in "awaiting returns" status - meaning licenses that were returned to the vendor for credit after they had been allocated by the MIE license allocation engine.  When the MIE encounters such "returns", if it has no unallocated licenses to remove in order to nullify the returns, it simply stages the returns, waiting until more licenses are purchased.  When the allocation optimizer runs, it attempts to nullify licenses awaiting returns by using un-allocated upbound license equivalents.  For example, if there are Visio 2003 licenses awaiting returns, and it is no longer possible to purchase Visio 2003 licenses, then the returns will never be nullified.  If Visio 2007 has been defined as an upbound equivalent of Visio 2003, the allocation optimizer will check to see if any un-allocated Visio 2007 licenses are available and use those to nullify the Visio 2003 licenses that are awaiting returns.  Only licenses that are new and have never been allocated will be used to nullify returns.  Essentially, such licenses are physically removed from the license pool (as if they never existed).  Licenses that are in the un-allocated pool due to harvesting will not be used.

2.De-allocate any licenses that were previously allocated as equivalents, however the equivalent definition has subsequently been removed meaning that such licenses are no longer equivalents, and the allocation is no longer valid.

3.De-allocate any licenses that were previously allocated to downbound equivalents, however the downbound equivalent is currently showing sufficient licenses to cover itself (eliminating the need for using upbound equivalent coverage).  Such de-allocated licenses will be re-distributed by the allocation post-processor by following its order of precedence.  When de-allocating upbound equivalents due to sufficient like-for-like license availability, the de-allocation will proceed in family order, with the lowest-numbered family member going first (which is usually the most current version)

4.De-allocate any licenses being consumed from higher upbound equivalents when unallocated licenses exist from a nearer upbound equivalent.  This de-allocation step is used to free up newer licenses when unallocated licenses are discovered, still upbound from the current need, but nearer in family order than licenses currently allocated.  For example, if Exceed 10 is currently being covered by 20 licenses being borrowed from Exceed 14, and the de-allocation pre-processor discovers 12 unallocated licenses for Exceed 12, then assuming Exceed 12 is also an upbound equivalent of Exceed 10, then 12 Exceed 14 licenses will be de-allocated from covering Exceed 10.  In the subsequent allocation post-processing step, those 12 newly uncovered Exceed 10 authorizations will be allocated the Exceed 12 licenses, resulting in the freeing up of 12 Exceed 14 licenses, which can then be used to cover other needs.

5.De-allocate any licenses that are currently allocated to assigned authorizations that match available constrained licenses, yet have previously been allocated an unconstrained license.  This frees up unconstrained licenses that have wider applicability than constrained licenses.  This is done for constraints - either at license level or via a constraint template - for Cost Center, Organization, Department, and Geography constraints.

Allocation post-processor

The allocation post-processor runs each time Consolidate runs, after all other operations but before license statistics are updated.  Its purpose is to scan through the entire pool of unallocated licenses, attempting, through an order of precedence, to allocate each license.  It will pick up new allocation opportunities created by either the de-allocation pre-processor or various configuration changes that may have been made to aliases and/or equivalents.  The allocation post processor follows the same allocation strategy as the triggered events.  It honors constraints and attempts allocation in the following priority order:

1.Awaiting returns

2.Like-for-like

3.Equivalents.

Within the priorities listed above, constrained licenses will be attempted to be allocated ahead of non-constrained licenses.  This will cause non-constrained licenses that were freed by the de-allocation pre-processor to be covered by matching constrained licenses, leaving the non-constrained licenses to be used elsewhere.

Any equivalent licenses freed by the de-allocation pre-processor will be assigned to cover like-for-like by the allocation post-processor.  This results in an optimized re-distribution of license allocation.