Behavior of Periodic Background Check

This section describes the behavior of the protected application for the following types of license issues:

Behavior for Missing License

This topic describes how the configuration tags <BACKGROUND_CHECK> and <IGNORE_BACKGROUND_CHECK> affect the behavior of the protected application when the connection between the application and the protection key is lost (for example, if the HL key is disconnected).

This description is relevant only when BACKGROUND_CHECK is assigned a value greater than zero (that is, background checks are not disabled).

If the License Manager detects that the protection key is missing when a background check is performed, a notification is displayed, and one or more of the following option buttons are provided (as explained afterward):

Button	Response by the application
Retry	The application checks for the presence of the protection key.
Abort	The application is terminated. (Unsaved work may be lost.)
Ignore	The application resumes operation for the number of seconds specified by BACKGROUND_CHECK. This provides the user with a grace period to save work-in-progress. At the end of the grace period, the License Manager checks again for the required protection key. If the protection key is not found, the application redisplays the missing license notification, providing the Retry, Abort, and Ignore buttons. The user can click Ignore to repeat this process up to the number of times specified by IGNORE_BACKGROUND_CHECK. (The number of remaining repeats is displayed in the notification.) If the protection key is still not found at that point, only the Retry and Abort buttons are provided.

Button

Response by the application

Retry

The application checks for the presence of the protection key.

Abort

The application is terminated. (Unsaved work may be lost.)

Ignore

The application resumes operation for the number of seconds specified by BACKGROUND_CHECK. This provides the user with a grace period to save work-in-progress.

At the end of the grace period, the License Manager checks again for the required protection key. If the protection key is not found, the application redisplays the missing license notification, providing the Retry, Abort, and Ignore buttons.

The user can click Ignore to repeat this process up to the number of times specified by IGNORE_BACKGROUND_CHECK. (The number of remaining repeats is displayed in the notification.) If the protection key is still not found at that point, only the Retry and Abort buttons are provided.

The process described above is triggered when the license for a specific Feature is not found. If at any point during the process, the required license for the specific Feature is found, the counter for grace periods is reset to the original number of periods specified. As a result, the process can start over if a license is again not found.

The value assigned to IGNORE_BACKGROUND_CHECK affects this process as described in the table that follows.

Value of IGNORE_BACKGROUND_CHECK	Option buttons provided in the notification
-1	Only the OK button is provided to dismiss the message box and to check again for the protection key. No grace periods are provided. This is the legacy behavior. (Default value)
0	Retry and Abort buttons are provided. No grace periods are provided.
1-254	Number of grace periods to provide. Retry, Abort, and Ignore buttons are provided at the end of each grace period. If all grace periods have been used, only Retry and Abort buttons are provided.
255	Retry, Abort, and Ignore buttons are provided, with unlimited grace periods. (However, the notification is displayed at the end of each grace period.)

NOTE For applications that may use the Executions license type and the Admin License Manager:

End users can configure the Admin License Manager session to time out after as little as 10 minutes of inactivity. If the background check interval is greater than the idle time-out interval and a time-out occurs, the background thread will again log in to the protection key. For applications licensed with the Executions license type, this could result in additional consumption of licenses. Therefore, Thales recommends that you do one of the following:

>Set a time interval of less than 600 seconds (10 minutes) for <BACKGROUND_CHECK> in order to prevent the session from timing out.

>Take other precautions to ensure that the end user does not set the idle time-out interval to a value lower than or equal to the <BACKGROUND_CHECK> interval.

Behavior for Expired License

This topic is relevant only when both of the following conditions are satisfied:

><BACKGROUND_CHECK> is assigned a value greater than zero (that is, background checks are not disabled).

>The license type for a Feature is Expiration Date.

This topic describes how the configuration tag <BACKGROUND_CHECK> affects an application whose expiration date passes while the application is active.

By default, the license expiration date of a Feature in a protected application is only checked when the application starts. If the license is valid at startup, the application is allowed to continue even if the expiration date passes while the application is running.

You have the option to set an attribute called die_at_expiration in the scope input XML tags for the LoginScope function. When enabled, this attribute causes the license expiration date to be checked each time a periodic background check is performed. If the background check determines that the expiration date of the Feature has passed, the application displays a message and offers to search for a valid license.

For details on specifying the login scope, see the <LOGIN_SCOPE> tag in the Sentinel LDK Envelope configuration file.