Managing Services Director Licensing

Overview of Services Director Licensing

The Services Director supports the following Software Licenses:

Cloud Services Provider (CSP) license - A CSP license supports all Services Director features (except vTM Analytics), and includes billing that is dependent on instance metering.

The registration, deployment and licensing of any number of Traffic Manager instances are supported, and there are no limits on the supported features or bandwidth they can use. Using a CSP license, the Services Director implements a metering scheme to obtain throughput and other metrics from each Traffic Manager instance on a regular basis (typically, hourly) and records the data in central log files.

Service providers and hosting organizations can use the metrics data to bill end users accordingly. Ivanti uses the same metrics data to charge the Services Director customer.

Enterprise license - An Enterprise license supports all pre-paid bandwidth and features. That is, the customer purchases Bandwidth Pack licenses, Enterprise Management Resource Pack licenses and (historically) Add-On Pack licenses from Ivanti to create licensed capacity which can be allocated to Traffic Managers. Bandwidth and features can be allocated up to the capacity purchased. Additional Bandwidth Packs, Enterprise Management Resource Packs and Add-On Packs can be purchased from Ivanti to allow further allocation. An Enterprise license does not provide a billing option. There is no requirement to collect and returned metering data to Ivanti.

Bandwidth Pack - A Bandwidth Pack license is a secondary type of license for Enterprise customers. Each Bandwidth Pack license provides a specific amount of bandwidth (for example, 5 Gbps) for a Traffic Manager SKU. Each Bandwidth Pack is tied to a specific Services Director Enterprise license. See Bandwidth Pack Licenses (Enterprise Customers Only).

Analytics Resource Pack - An Analytics Resource Pack license is a secondary type of license for Enterprise customers. Each Analytics Resource Pack license provides a specific amount of bandwidth (for example, 5 Gbps) to the ENT-ANALYTICS SKU. Each Bandwidth Pack is tied to a specific Services Director Enterprise license. See Analytics Resource Pack Licenses (Enterprise Customers Only).

Enterprise Management Resource Pack - An Enterprise Management Resource Pack license is a historical secondary type of license for Enterprise customers. It enabled Enterprise Management Features on a fixed number of vTMs. Each Enterprise License Resource Pack is tied to a specific Services Director Enterprise license. See Enterprise Management Resource Pack Licenses (Newer Licenses Only).

Add-On - An Add-On license is a historical secondary type of license that is compatible with older Services Director licenses only. It provides a mechanism for adding specific features. For example, Federal Information Processing Standards (FIPS), Ivanti Application Firewall (WAF), and Ivanti Aptimizer Web Accelerator. Each Add-On license is tied to a specific Enterprise License Key. See Add-On Licenses (Older Licenses Only).

The Services Director also supports Traffic Manager Flexible Licensing Architecture (FLA) Licenses. These are intended for the Traffic Manager instances rather than Services Director itself. With the FLA license you do not have to obtain licenses for individual Traffic Manager instances. Instead, the Services Director applies a FLA license to each instance, and dynamically sets the feature set and bandwidth required for each instance.

From Services Director v2.2 onwards, Universal FLA Licenses are provided with the installed product for both CSP and Enterprise customers. These are suitable for any Traffic Manager at version 10.1 or above which has its REST API enabled.

From Services Director v2.2 onwards, the term Legacy FLA Licenses refer to FLA licenses for any Traffic Manager at version 10.0 or earlier, or which has its REST API disabled. That is, it is not suitable for use with Universal FLA Licensing. Legacy FLA licensing can be added for older Traffic Manager versions, and requires a self-signed (or equivalent) certificate to be generated prior to its generation.

Retrieving Ivanti vTM and Services Director Product Licenses

License tokens are automatically emailed to you when you order your product. If you have not received your tokens, contact Ivanti Support.

Redeem license tokens at Ivanti’s website. To redeem tokens you must have a support site login and password. You can register for a new account at Ivanti Support.

Licenses are emailed to you as attachments.

Licensing on a Cluster of Services Directors

You can use a cluster of Services Directors (two or more) to provide resilience to your system.

Before starting the first Services Director in a cluster of Services Directors, you must place a valid license key file in the INSTALLROOT/licenses directory. New licenses in this location are automatically added to the database when the Services Director reboots and communication is established. A newly-installed Services Director that is configured to use an existing inventory database containing valid license keys will use those keys to operate after it has started.

Ivanti recommends that you install all subsequent Services Director licenses via the REST API’s controller_license_key resource. For details, see controller_license_key Resource.

For detailed information about installing Services Director licenses, see Installing the Services Director Software License.

Bandwidth Pack Licenses (Enterprise Customers Only)

A Bandwidth Pack is a secondary type of license that is tied to a specific Enterprise Services Director license.

For software form-factor installations of Services Director, Ivanti recommends that you add the Bandwidth Pack license to the shared database from a running Services Director using the REST API’s bandwidth_pack_license_key resource. For details, see bandwidth_pack_license_key Resource. However, you can also place the Bandwidth Pack license in the INSTALLROOT/licenses directory and restart the Services Director. New licenses are automatically added to the database as they are discovered.

Each Bandwidth Pack enables a specific amount of bandwidth (typically, 5 Gbps) to a Traffic Manager SKU. The Bandwidth Pack license allows you to deploy and license Traffic Manager instances with an aggregate bandwidth allowance equal to that of the Bandwidth Pack.

Each Bandwidth Pack is associated with one Services Director license and cannot be used unless that Services Director license has been loaded and found to be valid. A Bandwidth Pack only allows the deployment and licensing of Traffic Manager instances with one SKU. If you want to deploy Traffic Manager instances with different SKUs, then they require multiple Bandwidth Packs.

Services Director licenses and Bandwidth Packs are perpetual or they can have start and end dates.

Multiple Bandwidth Packs can license bandwidth for a SKU; their allowances are added to determine the total. Bandwidth Packs can be upgraded from one SKU to another. Where an existing Bandwidth Pack license is upgraded, a new license is issued with the same serial number as the existing one, but licensing a different SKU. Only one of a set of Bandwidth Pack licenses with a shared serial number is used at any one time.

The declared bandwidth for a vTM instance is used for both traffic bandwidth and analytics bandwidth.

Where licensed capacity is exceeded for a given SKU, all licensing requests for instances using that SKU are rejected. This behavior is also true of instances using an Add-On license SKU with insufficient licensed bandwidth.

If you are using a Bandwidth Pack license (or bandwidth from an Analytics Resource Pack) the Services Director does not allow you to exceed the licensed bandwidth with your deployed Traffic Manager instances. Instances with a status of Deleted do not count towards deployed totals. Any instance whose status is not Deleted continues to consume licensing bandwidth. The same rules apply to the consumption for Add-On license SKUs bandwidth for instances using Add-On SKUs.

Installing the Bandwidth Pack License (Enterprise Customers Only)

Place the license on an accessible location in your infrastructure. For details about obtaining your license keys, see Retrieving Ivanti vTM and Services Director Product Licenses.

Install and configure the Services Director. For details, see Installing and Configuring the Software Services Director.

Ivanti recommends that you add the Bandwidth Pack license to the shared database from a running Services Director using the REST API’s bandwidth_pack_license_key resource. For details, see bandwidth_pack_license_key Resource.

Alternatively, copy a Services Director license file containing the license key to the INSTALLROOT/licenses directory of an Services Director and restart the Services Director. New licenses are automatically added to the database as they are discovered.

Upgrading Bandwidth Pack Licenses (Enterprise Customers Only)

When your Services Director is using the Enterprise Licensing model, you can upgrade a bandwidth pack to support a different STM SKU. This supports the replacement of existing purchased licensing with the same quantity of a more feature-rich STM SKU.

For example, a deployment of Traffic Manager instances is using the STM-300 STM SKU, and an upgrade to the STM-400 STM SKU is required.

For each existing bandwidth pack license key being upgraded, the Administrator will be provided with two new bandwidth pack licenses keys:

The first license will contain the same serial number as the existing bandwidth pack license key.

Only one of these licenses can contribute licensed bandwidth in your Services Director deployment at any time.

The second bandwidth pack license key will be a time-limited key which provides extra bandwidth used during the switchover.

This provides a workaround for the Services Director’s protection against licensing compliance breaches.

To upgrade a Bandwidth Pack License:

Obtain the replacement (upgrade) license key and the supplementary temporary bandwidth pack license keys from Ivanti.

Install replacement and supplementary bandwidth pack license keys on the Services Director.

It may be necessary to set the upgrade bandwidth pack license key(s) to an Active status after installation. Once complete, the controller_license_key resource's cluster_bandwidth property should show sufficient unused STM-400 bandwidth for the instances that are to be switched to use this STM SKU.

Create a feature_pack resource using the STM-400 STM SKU if one does not already exist.

Set the feature_pack property of each affected Traffic Managerinstance resource to the desired STM-400 feature_pack resource (as created in step 3).

Remove the supplementary bandwidth pack license keys.

If the Services Director does not allow removal of the supplementary license keys, it may indicate a licensing shortage. This situation may result in unlicensed Traffic Managers after these keys expire.

Analytics Resource Pack Licenses (Enterprise Customers Only)

An Analytics Resource Pack license is a secondary type of license for Enterprise customers that is supported on “new style” Services Director licenses (the Services Director license number begins "LK1-BR-ADC").

Each Analytics Resource Pack is associated with one Services Director license and cannot be used unless that Services Director license has been loaded and found to be valid.

For a vTM in the estate of the Services Director to support vTM Analytics, its Feature Pack must include the ENT-ANALYTICS add-on SKU, and one or more Analytics Resource Pack Licenses must be added to the Services Director.

Each Analytics Resource Pack license provides a specific amount of bandwidth (for example, 5 Gbps) to any vTM whose Feature Pack includes the ENT-ANALYTICS add-on SKU. An Analytics Resource Pack license allows you to perform Analytics on Traffic Manager instances with an aggregate bandwidth allowance equal to that of the Analytics Resource Pack.

The declared bandwidth for a vTM instance is used for both traffic bandwidth and analytics bandwidth.

Analytics Resource Pack licenses are either perpetual, or they can have start and end dates.

Multiple Analytics Resource Packs can be applied to a Services Director; their allowances are added to determine the total.

Where licensed capacity is exceeded for the ENT-ANALYTICS SKU, all licensing requests for vTM instances using that SKU are rejected.

Enterprise Management Resource Pack Licenses (Newer Licenses Only)

An Enterprise Management Resource Pack Licenses is a historical license type that is supported on “new style” Services Director licenses (the Services Director license number begins "LK1-BR-ADC"). Enterprise Management Resource Pack Licenses are not compatible with “old style” Services Director licenses.

A Enterprise Management Resource Pack is a secondary type of license that is tied to a specific Enterprise Services Director license. It enables Enterprise Management Features on a fixed number of vTMs.

Features that require an Enterprise Management Resource Pack License are:

vTM Analytics Export.

The SKUs from the Enterprise Management Resource Pack License can be combined with base SKUs when the user creates a Feature Pack to enable Enterprise Management features on any vTM (up to the defined limit) that uses the Feature Pack.

Currently, Enterprise Management Resource Pack Licenses are available to Enterprise customers only.

Add-On Licenses (Older Licenses Only)

An Add-On License is a historical license type, that is only supported on “old style” Services Director licenses (the Services Director license number begins "LK1-ERSSC"). Add-On Licenses is not compatible with “new style” Services Director licenses.

An Add-On license is a secondary type of license that is tied to a specific Enterprise License Key. Each Add-On license contributes license bandwidth for a single specific feature, known as an Add-On SKU. These Add-On SKUs can be combined with base SKUs when the user creates a Feature Pack. For an instance set to use such a Feature Pack, the feature capabilities of the base SKU are augmented by those of the Add-On SKU.

Add-On SKUs can be used with CSP licensing model, and do not require the use of an Add-On license.

The Services Director supports the following Add-On licenses:

Federal Information Processing Standards (STM-B-ADD-FIPS, STM-CSP-U-ADD-FIPS)

Ivanti Application Firewall license (STM-B-ADD-WAF, STM-CSP-U-ADD-WAF)

Ivanti Aptimizer Web Accelerator (STM-B-ADD-WEBACCEL, STM-CSP-U-ADD-WEBACCEL)

Add-On licenses have unique serial numbers and do not support upgrades.

Installing an Add-On License

To retrieve an Add-On license, you are sent a token via email to redeem at Ivanti Support.

Place the licenses on an accessible location in your infrastructure. For details about obtaining your license keys, see Retrieving Ivanti vTM and Services Director Product Licenses.

Install and configure the Services Director.

Ivanti recommends that you add the Add-On license to the shared database from a running Services Director using the REST API’s add_on_pack_license_key resource. For details, see add_on_pack_license_key Resource.

Working with Traffic Manager FLA Licenses

Traffic Manager Flexible Licensing Architecture (FLA) License - A Traffic Manager FLA license is intended for the Traffic Manager instances rather than Services Director itself. With the FLA license you do not have to obtain licenses for individual Traffic Manager instances. Instead, the Services Director applies a site-specific license to each instance and dynamically sets the feature set (SKU) and bandwidth desired for each instance. The FLA license requires a self-signed (or equivalent) certificate to be generated prior to its generation.

From Services Director v2.2 onwards, Universal FLA Licenses are provided with the installed product for both CSP and Enterprise customers. These are suitable for any Traffic Manager at version 10.1 or above which has its REST API enabled.

From Services Director v2.2 onwards, the term Legacy FLA Licenses refer to FLA licenses for any Traffic Manager at version 10.0 or earlier, or which has its REST API disabled. That is, it is not suitable for use with Universal FLA Licensing. Legacy FLA licensing can be added for older Traffic Manager versions.

Universal FLA is available automatically when the product is installed, but all of the procedures in this section are supported by both Universal FLA and Legacy FLA.

Generating a Self-Signed SSL Server Certificate

This section is supported by both Universal FLA and Legacy FLA. Universal FLA is available automatically when the product is installed, but you must still supply an SSL certificate for it.

The Services Director is commonly deployed using self-signed certificate/key pairs, using the self-signed server certificate in the FLA license.

The following information is required to generate a Legacy Traffic Manager FLA license:

A list of the fully-qualified host names that is used for Services Directors acting as license servers, along with port numbers.

The SSL server certificate that is used by all of the Services Directors (different controllers are not permitted to use different certificates).

An FLA license attempts to contact each of the listed license servers in turn, until it makes a successful connection or has attempted and failed to contact each one.

The SSL server certificate is verified by the FLA license. If an SSL server certificate does not match what is required by the FLA license, then that FLA license will not connect to the Services Director license servers. If this failure occurs, you may need to generate a new FLA license or correct the key/certificate used by the Services Director.

At the Linux prompt, enter:

$ openssl req -x509 -nodes -newkey rsa:2048 -keyout key.pem -out cert.pem -days 3650

Parameter	Description
req	Specifies an X509 certificate signing request management.
-x509	Specifies a self-signed certificate rather than a certificate request.
-nodes	Specifies that the private key will not be encrypted (otherwise, the server needs a password to start).
-newkey rsa:2048	Generates a new certificate request and sets the key size.
-keyout key.pem	Sets the target for the new private key.
-out cert.pem	Sets the target for the certificate.
-days 3650	Specifies the duration of the certificate (default is 30 days). A longer period may be desirable as a fresh FLA license will need to be generated and then deployed to all STM instances when the certificate expires.

The FLA license does not accept composite certificates that include a server certificate along with other information or certificates created by ssh-keygen.

Verifying the SSL Certificate

At the prompt, enter:

$ openssl x509 -in certificate.crt -noout

This command succeeds silently for a valid certificate or report errors.

To verify signed certificates, at the system prompt, enter:

$ openssl verify <certificate name>

Installing FLA Licenses

Universal FLA is available automatically when the product is installed, but this section is supported by both Universal FLA licenses and Legacy FLA licenses.

The Traffic Manager FLA license is installed by placing the FLA license file in the configured sources directory (the location for the Traffic Manager image and FLA license files), and then creating a license resource via the Services Director REST API.

Choose a source location for FLA licenses. This is used during the installation process for the Services Director. For detailed information, see Required Configuration Parameters.

Place the license file in the location chosen in step 1. For details about obtaining your license keys, see Retrieving Ivanti vTM and Services Director Product Licenses.

Install and configure the Services Director. For details, see Installing and Configuring the Software Services Director.

Create a REST API license resource in the Services Director REST API. For details, see license Resource.

Checking the Health of an FLA License Manually

This section is intended for use with Legacy FLA Licenses, and applies to all customers. No equivalent actions will be required for Universal FLA Licenses.

The Services Director supports an FLA Health Checker. This tool enables you to manually test the licensing of all your resources against an FLA license. This enables you to identify any licensing problems with the FLA before any instances start using it.

You will typically run the FLA Health Checker immediately after creating the dependent resources for instance deployment. That is, host, license, feature pack, and version.

The health of an FLA license is checked automatically under some circumstances. See Checking the Health of an FLA License Automatically.

You start the FLA health checker using the REST API. To do this, issue a GET REST API request for the license resource, including the URL parameter status_check=true.

The response from the GET request will depend on the success of this operation.

Initially, the health_check_status property indicates that the FLA health check has started in the background, and is in progress.

For example:

{ "generic_errors" : null,
"health_check_results" : [ ],
"health_check_status" : "In Progress",
"info" : "",
"last_health_check_time" : "<timestamp>",
"status" : "Active"
}

You can then poll the URI with normal GET request until the health check completes.

Only one FLA health check can be running at any time.

When a health check completes successfully:

the health_check_status is set to Completed.

the health_check_result is Passed.

the details property is empty.

For example:

{ "generic_errors" : null,

"health_check_results" : [ {

"details" : { },

"health_check_result" : "Passed",

"instance_host" : "<instance_host>.com",

"services_director_host" : "<sd_host>:<port>",

"services_director_port" : <port>

} ],

"health_check_status" : "Completed",

"info" : "",

"last_health_check_time" : "<timestamp>",

"status" : "Active"

}

When the health check completes with SSL connection errors:

the health_check_status is set to Completed.

the health_check_result is Failed.

the details property includes the SSL errors.

For example:

{ "generic_errors" : null,
"health_check_results" : [{
"details" : {
"ssl_errors" : {
"errors" : [{
"err_code" : 18,
"err_text" : "Services Director sent a self-signed
certificate which cannot be trusted"
}],
"fla_certs" : [{
"common_name" : "<common_name>",
"issuer_common_name" : "<issuer_common_name>",
"not_after" : "20150529135614Z",
"not_before" : "20130529135614Z"
}],
"services_director_certs" : [{
"common_name" : "<common_name>",
"issuer_common_name" : "<issuer_common_name>",
"not_after" : "20240513142858Z",
"not_before" : "20140514142858Z"
}]
}},
"health_check_result" : "Failed",
"instance_host" : "<instance_host>",
"services_director_host" : "<sd_host>:<port>",
"services_director_port" : <port>
},
{ "details" : {
"ssl_errors" : {
"errors" : [{
"err_code" : 18,
"err_text" : "Services Director sent a self-signed
certificate which cannot be trusted"
}],
"fla_certs" : [{
"common_name" : "",
"issuer_common_name" : "",
"not_after" : "20150529135614Z",
"not_before" : "20130529135614Z"
}],
"services_director_certs" : [{
"common_name" : "<common_name>",
"issuer_common_name" : "<issuer_common_name>",
"not_after" : "20240513142858Z",
"not_before" : "20140514142858Z"
} ]
} },
"health_check_result" : "Failed",
"instance_host" : "<instance_host>",
"services_director_host" : "<sd_host>:<port>",
"services_director_port" : <port>
}
],
"health_check_status" : "Completed",
"info" : "test",
"last_health_check_time" : "<timestamp>",
"status" : "Active"
}

In the above response, the ssl_errors property included:

the details of the errors (errors )

the certificate embedded in the FLA (fla_certs ).

the details of the certificate sent by the Services Director (services_director_certs ).

When the health check completes with network related errors:

the health_check_status is set to Completed.

the health_check_result is Failed.

the details property includes the network errors.

For example:

{ "generic_errors" : null,
"health_check_results" : [{
"details" : {
"network_errors" : "Failed to resolve SSC host '<sd_host>':
Name or service not known"
},
"health_check_result" : "Failed",
"instance_host" : "<instance_host>",
"services_director_host" : "<sd_host>:<port>",
"services_director_port" : <port>
},
{ "details" : {
"network_errors" : "Failed to resolve SSC host ‘<sd_host>':
Name or service not known"
},
"health_check_result" : "Failed",
"instance_host" : "<instance_host>",
"services_director_host" : "<sd_host>:<port>",
"services_director_port" : <port>
}
],
"health_check_status" : "Completed",
"info" : "test",
"last_health_check_time" : "<timestamp>",
"status" : "Active"
}

The generic_errors top level property specifies errors that may happen while carrying out FLA health checks, but which is not related to the actual FLA health check. For instance, if there are no active hosts to carry out the checks.

Checking the Health of an FLA License Automatically

This section is intended for use with Legacy FLA Licenses, and applies to all customers. No equivalent actions will be required for Universal FLA Licenses.

The Services Director supports an automated FLA Health Checker. This tool tests the FLA license as part of the following activities:

The deployment of a new Traffic Manager instance.

If the FLA license check fails, the deployment action status is Blocked, with a reason for the failure. The instance has a status of Failed to Deploy.

If the FLA license check succeeds, the deployment continues. Once this action completes, the instance has a status of Idle.

When you create a service, the deployment of a new Traffic Manager service instance does not trigger the FLA Health Checker.

Any attempt to transition a Blocked deployment action to a status of Waiting.

If the FLA license check fails, the deployment action remains Blocked, with a reason for the failure.

If the FLA license check succeeds, the deployment continues. Once this action completes, the instance has a status of Idle.

Any change to the FLA license of a deployed Traffic Manager instance. When the new license is applied, the instance is checked against the new FLA license.

If the FLA license check fails, the update action for the instance is Blocked, with a reason for the failure. The status of the instance is unchanged.

If the FLA license check succeeds, the status of the instance is unchanged.

This enables you to prevent any FLA licensing problems before they occur.

When you perform a deployment manually through the REST API, you can specify a URL parameter ?override_fla_check=true to prevent the automatic FLA license check before deployment. This is not supported from the Services Director VA.

You are able to disable the operation of the FLA Health Checker at the Services Director level. See Disabling the FLA Health Checker.

You can check the health of an FLA license manually at any time. See Checking the Health of an FLA License Manually.

Disabling the FLA Health Checker

To disable the FLA Health Checker at the Services Director level, either:

In the REST API, make a call to the /api/tmcm/2.9/settings/fla_check resource, with the following JSON object:

{"fla_checker_enabled": False}

In the Services Director VA, disable the check from the System > Service Status page.

Reapplying a FLA License

If you want to re-license a Traffic Manager using its assigned FLA license, use the REST API. For example:

$ curl -v -k --basic -H "Content-Type: application/json" -H "Accept: application/json"
-u user:passwd https://x.x.x.x:8100/api/tmcm/2.9/instance/<instance_name>?relicense=true -d '{ }'