Upgrading Sentinel HL Keys
The configuration of Sentinel HL keys can be upgraded before or after delivery to customers as follows:
>Sentinel HL (HASP configuration) keys can be upgraded to Sentinel HL (Driverless configuration) keys.
>Sentinel HL (Driverless configuration) standalone (non-Net) keys can be converted to Sentinel HL (Driverless configuration) network keys.
Each of these upgrades is described below.
This section also describes Differences Between Sentinel HL (Driverless configuration) keys and Sentinel HASP keys.
Upgrading a Sentinel HL Key to Driverless Configuration
A Sentinel HL (HASP configuration) key that was previously delivered to a customer can be upgraded to a Sentinel HL (Driverless configuration) key in the field. In Driverless configuration, this key will employ HID drivers instead of HASP key drivers. (HID drivers are an integral part of the operating system.) As a result:
>The key is less subject to issues related to operating system upgrades.
>The key may no longer require the presence of Sentinel LDK Run-time Environment.
All of the licenses and key memory that existed in the Sentinel HL (HASP configuration) key will continue to exist in the key after the upgrade.
NOTE Given the following situation:
>An application is protected with version 6.3 or 6.4 of Sentinel Licensing API libraries and/or Envelope.
>The Sentinel HL (HASP configuration) key that licenses the application is upgraded to the Driverless configuration.
The application will work correctly after the upgrade. However, the requirement for the presence of the Run-time Environment does not change.
The tables that follow summarize the requirements for working with HL keys.
Standalone HL Keys
Version of Licensing API or Envelope used to protect the application (lower of the two) | HASP HL key or Sentinel HL (HASP configuration) key | Sentinel HL (Driverless configuration) key |
---|---|---|
HASP SRM, Sentinel HASP, or Sentinel LDK v.6.0 or v.6.1 | Requires Run-time Environment from same (or later) version that was used to protect the application | Not supported. See the warning below. |
Sentinel LDK v.6.3 | Requires Run-time Environment from Sentinel LDK v.6.3 or later | |
Sentinel LDK v.6.4 | Requires Run-time Environment from Sentinel LDK v.6.4 or later | |
Sentinel LDK v.7.0 or later | Requires Run-time Environment from Sentinel LDK v.7.0 or later | Under Windows, use of Run‑time Environment (from Sentinel LDK v.7.0 or later) is optional. |
Net and NetTime HL Keys
Version of Licensing API or Envelope used to protect the application (lower of the two) | HASP HL key or Sentinel HL (HASP configuration) key | Sentinel HL (Driverless configuration) key |
---|---|---|
HASP SRM, Sentinel HASP, or Sentinel LDK v.6.0 or v.6.1 | On the machine where the HL key is connected: Requires Run-time Environment from same (or later) version that was used to protect the application | Not supported. See the warning below. |
Sentinel LDK v.6.3 | On the machine where the HL key is connected: Requires Run-time Environment from Sentinel LDK v.6.3 or later | |
Sentinel LDK v.6.4 | On the machine where the HL key is connected: Requires Run-time Environment from Sentinel LDK v.6.4 or later | |
Sentinel LDK v.7.0 or later | On the machine where the HL key is connected: Requires Run-time Environment from Sentinel LDK v.7.0 or later |
The following limitations apply:
>The application must be protected using version 6.4 or later of Sentinel Licensing API libraries and/or Envelope. (For Sentinel HL Net keys and Sentinel HL NetTime keys, use version 7.0 or later.)
>You must be using version 6.4 or later of Sentinel LDK-EMS or License Generation API to generate the Product that upgrades the HL key. (For Sentinel HL Net keys and Sentinel HL NetTime keys, use version 7.0 or later.)
>The firmware on the Sentinel HL key will be automatically updated as part of the upgrade process.
>After upgrade, Sentinel HL (Driverless configuration) keys will not be visible in Admin Control Center if the Run-time Environment is earlier than:
• version 6.50 (Sentinel LDK v.6.3) — for standalone keys
•version 6.60 (Sentinel LDK v.7.0) — for Net and NetTime keys
An application that is protected with version 6.3 of Sentinel LDK, Licensing API libraries and/or Envelope will work correctly after the Sentinel HL (HASP configuration) key that licenses the application is upgraded to the Driverless configuration. However, the requirement for the presence of the Run-time Environment does not change.
**WARNING**
An application that is protected with version 6.1 or earlier of Sentinel LDK libraries, Licensing API libraries and/or Envelope will stop working if the Sentinel HL (HASP configuration) key that licenses the application is upgraded to the Driverless configuration.
The upgrade process for the Sentinel HL key is not reversible.
Upgrade Requirements
The machine that is used to upgrade a Sentinel HL (HASP configuration) key to a Sentinel HL (Driverless configuration) key must contain a Sentinel LDK Run-time Environment that satisfies the following requirements:
Sentinel HL (HASP configuration) key to upgrade | Required Run-time Environment |
---|---|
Standalone key that contains license information (Features and Products) | Version 6.56 or later |
Net or NetTime key that contains license information (Features and Products) | Version 6.60 or later |
Any HL key that contains no license information (Features and Products) AND the license update used to upgrade the key contains no license information (Features and Products). Both the key and the license update can contain memory data. | No special version requirements |
Upgrade Process
To upgrade a Sentinel HL (HASP configuration) key to Sentinel HL (Driverless configuration) key:
>Create a
The Upgrade to Driverless attribute is ignored if it applied to Sentinel HASP keys or to Sentinel HL (Driverless configuration) keys. Similarly, the attribute is ignored if is applied to an SL AdminMode key, SL UserMode key, or SL Legacy key. No error message is generated.
The Product that contains the Upgrade to Driverless attribute can be created using Sentinel LDK-EMS
To upgrade a Sentinel HL Basic key from HASP configuration to Driverless configuration:
>On the machine where the Sentinel HL Basic key is connected, use RUS to collect information regarding the key. Use the resulting C2V file with Sentinel License Generation API to generate a V2C file that uses the Upgrade to Driverless attribute to upgrade the key.
Apply the V2C file to the Sentinel HL Basic key to be upgraded.
Converting a Sentinel HL Standalone Key to a Network Key
This topic does not apply to Sentinel HL Basic keys.
The table that follows describes the terminology used in this section.
Sentinel HL standalone keys can be updated, before or after delivery to end users, to Sentinel HL concurrency-enabled keys, and thus provide practically the same network functionality as Sentinel HL Net or NetTime keys.
The only difference between a Sentinel HL concurrency-enabled key and a Sentinel HL Net or NetTime key is the manner in which you are charged for network seat licenses. Each Net or NetTime key is provided with a number of network seat licenses, based on the type of key. For HL concurrency-enabled keys, network seat licenses that you provide to your customers are deducted from the HL Pool of Seats in your Sentinel LDK Master license. This is similar to the way network seats are charged for Sentinel SL keys.
You update a Sentinel HL standalone key to a Sentinel HL concurrency-enabled key simply by assigning concurrency to a Feature on the key. When this occurs, the License Manager checks the firmware version of the key and may upgrade the firmware. (For more information on firmware upgrades, see the description of firmware in the Sentinel LDK Release Notes.)
The conversion can only occur if License Manager v.7.3 or later is present on the machine where the Sentinel HL key is connected.
NOTE When you update a Sentinel HL standalone key to a Sentinel HL concurrency-enabled key, you must also ensure that the Sentinel LDK Run-time Environment is installed on the machine where the key is connected. For more information, see Situations That Require Sentinel LDK Run-time Environment.
Note the following:
>Feature ID 0 for a Sentinel HL concurrency-enabled key shows the key as a NET key with unlimited concurrency as long as any other Feature on the key requires concurrency. If the requirement for concurrency are removed from the key, Feature ID 0 will show the key as a standalone key.
>In Sentinel License Generation API, you can prevent the upgrade of the Firmware for a Sentinel key when you update a license. However, if the existing Firmware on the key does not support the functionality in the update you are attempting to perform, the update will fail as a result. For more information, see the Sentinel License Generation API Reference.
>All Sentinel HL (Driverless configuration) key (except for HL Basic keys) will be shown as capable devices for licenses that require concurrency.
Sentinel HL (HASP configuration) standalone keys can be upgraded and updated to Sentinel HL (Driverless configuration) concurrency-enabled keys in a single update operation. Upgrade the key to the Driverless configuration as described earlier in this appendix, and at the same time assign concurrency to a Feature on the key.
Differences Between Sentinel HL (Driverless configuration) keys and Sentinel HASP keys
There is differences between Driverless keys and HASP keys when applying license update files (V2C or V2CP files, all referred to below as V2C updates).
>For HASP keys:
Sentinel LDK does not support applying a given V2C update multiple times. If the process of applying a V2C update to a HASP key is interrupted before completion, an additional attempt to apply the same V2C update will fail.
>For Driverless keys:
A given V2C update can be applied multiple times. After the first successful application of the V2C update, any additional attempts to apply the V2C update are simply ignored. If the process of applying a V2C update to a Driverless key is interrupted before completion, you can attempt to apply the same V2C update additional times until it succeeds.
However: If the customer uses the same C2V file to generate two different V2C updates, then after applying the first V2C update, the second V2C update might be applied partially to the Driverless key. Thales recommends that customers make sure that a given C2V file is only submitted to the vendor once to avoid this issue.