Modules > Asset Management > Process > Catch Points

When a technician swaps a hard drive from a bad asset to a working asset, the MSL authorizations currently assigned to the bad asset need to be moved and re-assigned to the working asset. This Catch Point function manages that move. This Catch Point can also be used to transfer MSL applications from any old asset to a new asset.

Transfer MSL Authorizations is a function provided by Asset Management's Catch Point screen management function. Screens designed to perform this function generally include the following items of information:

Asset Number FROM	The asset number of the broken or old asset.
Asset Number TO	The asset number of the working or new asset.
User FROM	The user from which the authorizations are to be transferred (applies only to authorizations that are assigned to named users)
User TO	The user to which the authorizations will be transferred.
Authorizations to transfer	Optionally allows selecting which authorizations to transfer. The default is to transfer all authorizations.
Technician name	The name of the person performing the transfer.
Ticket number	The repair or dispatch ticket number that authorized the repair or installation action.

The MIE will not transfer authorizations to the TO asset if the TO asset is currently set to a status value that has been defined for status-based harvesting. Otherwise, as soon as the authorizations were transferred, they would be immediately harvested. A warning is returned notifying the technician that the authorizations were not moved and the reason.

Otherwise, when presented with these four data items, the MIE will transfer MSL applications from one asset to the other using the following business rules:

Case	Action
MSL application, or a defined license equivalent, already exists on the TO asset and the license covering the FROM asset is constrained to that asset.	No transfer will take place as the license cannot be used to cover any other asset.
MSL application, or a defined license equivalent, already exists on the TO asset and the license unit count required to cover/allocated to the FROM asset differ from the license unit count required to cover/allocated to the TO asset. (this is can happen with server-based licensing when attempting to transfer from one server to another)	No transfer will take place. For complex transfers, the MSL application must first be harvested from the TO asset.
MSL application, or a defined license equivalent, already exists on the TO asset and either the FROM asset or the TO asset have more than one license unit allocated via more than one license record (multiple license blocks being used to cover multi-unit requirements - usually for server-based licensing)	No transfer will take place. For complex transfers, the MSL application must first be harvested from the TO asset.
MSL application, or a defined license equivalent, already exists on the TO asset, yet no license coverage exists on either the FROM asset or the TO asset.	The transfer will be recorded in the FROM asset's authorization record, and authorization will be removed from the FROM asset. A credit will be staged.
MSL application, or a defined license equivalent, already exists on the TO asset and has either been covered by a license or charged for the authorization.	No transfer will take place. The user will be notified that the MSL application should be harvested from the FROM asset.
MSL application, or a defined license equivalent, already exists on the TO asset, however it has not been covered by a license and no charge has been assessed AND no other case defined in this table where the TO asset already has the MSL application or its equivalent authorized applies. The FROM asset is covered by a license that will also cover the TO asset's application.	The application license(s) will be transferred. History information about the transfer will be stored in the Authorized Software table under the FROM asset. Authorization will be removed from the FROM asset. Credit(s) will be staged for the authorization(s) removed.
MSL application, or a defined license equivalent, does not exist on the TO asset.	The application license(s) will be transferred if they are not constrained to the FROM asset. If the license(s) is/are constrained to the FROM asset, authorization will be established for the TO asset, however only license(s) (if any) that are not constrained will be transferred. If any constrained license(s) remain with the FROM asset, then the FROM's asset authorization will also remain and those license(s) will have to be harvested from the FROM asset. History information about the transfer will be stored in the Authorized Software table under the FROM asset if no license constraints exist. The FROM asset's authorization will be removed if no constrained licenses exist after transfer. Credits/debits are not impacted as this is a neutral transfer of authorization from one asset to another.
MSL application does not have Item is officially on the MSL checked (meaning the application is not an official MSL application). This setting is available under the Managed Software menu option, which is available (given proper access) from the Asset Management home page.	No transfer will take place. The user will be notified that the application is not an official MSL application and therefore cannot be transferred.

There may be an instance of a FROM asset that contains an older version of an application, and a TO asset that contains the newer version of the same application. If the newer version has been established as a license equivalent, then generally the application will not be transferred. If the TO asset is not covered by a license, the FROM asset's license will be transferred IF it can cover the TO asset's installation. (For example, if Office 2000 exists on the FROM asset and is covered by an Office 2000 license, and Office 2003 exists on the TO asset, without license coverage, the license will not be transferred as an Office 2000 license generally cannot cover an Office 2003 install.)