Revoking Redundant Licenses

Revocation of redundant licenses is introduced since the 8.5.5 (Windows) and 8.6.0 (UNIX) releases. The diagram below summarizes the workflow of revoking redundant licenses:

Here are the steps in detail.

Step 1 - Customer Contacts software vendor for License Revocation

The customer sends a request to you to revoke license(s).

Step 2 - Vendor Requests for the Locking Code of the Target Systems

You request the customer to send the locking codes of the License Managers on which the license(s) to be revoked is hosted.

Notes:

>For license revocation, ensure that only a new style locking code is obtained. Also, the locking code must be for locking criteria which are available at the time. Locking code enumeration takes place in case multiple instances of the locking criteria are available.

>All locking criteria, except the standard custom, support license revocation.

Step 3 - Customer Obtains Locking Information and Sends it to Vendor

The customer obtains the locking information (locking criteria\selector and the locking code) of all the systems, participating in the redundant pool, using Wechoid, echoid, or a custom utility that you have provided to them. The locking information is passed to you.

Step 4 - Vendor Generates the Permission Ticket and Sends it to Customer

You need to use the API VLSgeneratePermissionTicketExt2 for generating the permission ticket. A single permission ticket generated thereby is valid for all the License Managers. Since this permission ticket is to be executed on all the License Managers in the pool, it contains locking information of all of them. To allow this, a new permission ticket request structure VPT_REQUEST_EXT3 is introduced in the 8.5.5 release that allows an array of the lock selector and locking code fields. Refer to the Sentinel RMS SDK API Reference Guide for more details.

The permission ticket contains a field “license line,” which specifies the license string(s) to be revoked.

You then pass the generated permission ticket to the customer.

Step 5 - Customer Generates the Revocation Ticket and Sends it to Vendor

The customer or their system administrator executes the received permission ticket using the VLSrevokeByPermissionTicketExt API (or an option\utility that calls this API) on all the targeted License Managers. On each License Manager, a corresponding revocation ticket is generated. All these revocation tickets are to be passed to you for verification.

Step 6 - Vendor Verifies and Decodes the Revocation Ticket

Using the VLSverifyRevocationTicketExt2 API function, you can verify all the revocation tickets obtained against the single permission ticket to determine whether revocation was performed on all the targeted License Managers and if there are any missing or duplicate revocation tickets. The API allows an array of structures for specifying multiple revocation tickets and also for obtaining the locking information of the missing revocation tickets.

Finally, after successful verification, you may choose to decode the revocation ticket. It can be done using the VLScgDecodeLicenseRevocationTicketExt API or the following command in the lsdecode utility:

lsdecode –rt revocation-ticket-file