Capturing Software Usage Data with K2-KeyServer

Capture Software Usage Data

Best Practices for correctly configuring Policies to track and manage software usage.

K2-KeyServer can conduct many activities to support your organization’s IT management goals. It handles Software Asset Management (SAM), Hardware Asset Management (HAM), Software License Management (SLM), software usage tracking and optimization of computing resources (both software and hardware). K2 also supports IT Procurement operations and contributes to many other key IT process areas like vendor, contract, and security management.

Two of K2’s main activities are discovering computers and software for audit reports, and tracking usage of those computers and software for usage reports. These two main activities facilitate optimization of IT resources for cost reduction and make all of the other activities mentioned above possible.

No special configuration settings are necessary for K2 to discover computers and software or to capture computer usage (logins). All that is required for those actions is for the client agent, KeyAccess, to be installed with the KeyServer address. But K2 will not capture software usage until Policies have been created.

There are three different actions that a Policy can take when software is launched: it can Manage, Observe, or Deny software usage. We recommend using a “Manage” Policy for any software product that is licensed to your organization, an “Observe” Policy for freeware or open source software that you wish to track, and a “Deny” Policy for software that you want to block access to.

During my years spent guiding the development of the ISO/IEC 19770-3 ITAM Standard for Entitlements, I came to appreciate the richness and complexity of software license metrics.

You may also use combinations of Policies to manage different levels of usage to different groups of clients. For instance, you might use two different Manage Policies to track and manage usage of different licensing contracts for different operating divisions in your organization. And then use either a Deny Policy to restrict access elsewhere, or an Observe Policy to give your team visibility to usage in areas where the software is not licensed for use.

If your organization is paying support costs for open source software based on utilization levels, you might benefit more from the more detailed information collected by a Manage Policy. Following are configuration guidelines for each of the three types of Policies.

Prerequisites: The following instructions work best after computers have logged in, been audited, and the Product Recognition Service (PRS) has done at least its first run. These prerequisite actions will automatically populate the Products table with discovered software products that can be managed by K2.

K2 Policy Configuration – “Manage” Policy

Start with a Purchase record

If a software product is licensed to your organization it is best to begin Policy construction by entering Purchase details. This helps to ensure you’re recording correct product, license metric and entitlement details. Purchase records will make it convenient to track version upgrade rights throughout the life of a software product family and also provide proof of license to protect your organization in the event of a compliance audit.

Software Product RecognitionPrerequisite: Find or Create a Product record

To begin, open the Products window (or bring it forward by clicking inside the window) and select “Find…” from the Edit menu. Type a part of the product name that you wish to work with and hit enter. This will select the first match. Then click the “dot” icon to the left of the search field to open a window showing all matches. If the product doesn’t appear, then select “Find Product Definitions…” from the Tasks menu, type the identifying word or phrase and click “OK”. If the product still doesn’t appear, then refer to “Manually Creating Accurate Product Definitions.”

Optional Cross-platform Product

The K2 Product Catalog contains both platform specific Products and cross-platform Products for Adobe products. But product records for most other publishers are platform specific only. If your organization has purchased cross-platform licensing and K2 does not have a cross-platform version record, you can quickly create one by selecting “New Product…” from the Tasks menu.

In the first page of the Product Wizard, copy the Name, Version, Publisher, Category and Release Date details from one of the platform-specific records for this product, making sure to indicate this one is multi-platform. In the next page, drag in all of the Application programs from the two platform-specific Products. There is an optional “Suggestions” page that might appear next. If so, ignore it for the purpose of this work flow and go to the next. If there is a previous multi-platform version of this product in the Products list, you can add it to the Previous Product field in this page. In the final Wizard page you can review your settings and, if they are okay, click Finish to transfer all of the information you just entered to the Product Details window where it can be viewed, edited, or augmented.

Refer back to the platform specific Products that you used to build this cross-platform product. If there are any Programs listed under the “Utilities” section of the Programs panes of either of the original Products, then in your newly created multi-platform Product; drag those same Programs below the Utilities line and save the record.

Add a Purchase Wizard

Once you have located or created the Product record, right-click on it and select “New Purchase…”. This will open the first page of the Purchase Wizard. If you need guidance for entering purchase details, refer to documentation for Add a Purchase Wizard.

Reconcile Software LicensingReconcile Purchases with Policy Management

When you have completed data entry for the purchase details, right-click in the saved Purchase window and select Reconcile. When the Reconcile window opens, the purchase record is selected on the left side and some details about the purchase are displayed on the right. Change the selection on the left side to the product name immediately above the selected purchase. This will change the display on the right side to show a summary of entitlements for the product based on all purchases for the selected license metric. One or more recommendations will be displayed at the bottom right.

Assuming this is the first purchase entry for this product and no Policies have been created for it yet under the selected license metric; the single recommendation should be to “Create New Policy”. Click on that recommendation and then click the “Apply” button below it. This will create a pre-configured “Manage” Policy using the entitlement settings from the Purchase record. The Policy is opened so you can check details and make adjustments to the settings.

For in-depth documentation on Product Reconciliation, see the documentation on “Product Reconciliation Window” and the “Reconcile Wizard.”

Adjusting the Policy Settings

There are a few items to consider for fine-tuning in the license Policy. If the Purchase record was entered for cross-platform product licensing, then you should add the platform-specific (Windows, Macintosh, Linux) Products to this and any other related Policy. This will enable the Compliance reports to recognize installed Products, correctly analyze entitlement consumption, and accurately report Effective License Position (ELP).

K2 Software Entitlement Policy

Each Policy can Manage, Observe, or Deny access to software

Policy Scope & Action

In the “Scope & Action” pane you will see fields for “Section” and “Scope”. Both of these settings will limit the influence of the Policy to specific clients. See link below for details on Section management. The default setting for Policy Scope is “Universal”, meaning that this Policy will influence and track the usage of the managed software on all clients that are supported by this KeyServer – whether they are currently connected or “off-line”. When a Group name is applied to the Scope, the Policy will ignore use of the managed software on all clients except those within scope – and it will either Manage, Observe or Deny software access on those clients that are in-scope.

The settings for Action, Metric, and Entitlements were automatically configured from the details you entered into the Purchase record. You should not make any changes to these three settings. You can learn more about these settings in the documentation.

Enforcement: (Strict, Relaxed, or None)

Enforcement can be set to Strict, Relaxed or None. Follow the links below for an in-depth technical discussion of these settings. Each Metric (Site, Concurrent, Lease, Node, User, User Lease, PVU, Core, Socket and Custom Formula) responds in various ways to the Enforcement setting. Two simple behavior models can be illustrated using Concurrent Use and Node locked metrics. The behavior for other metrics is similar to one of these cases.

For the Concurrent metric, strict enforcement requires client computers to maintain a connection to KeyServer throughout use of the policy. Offline usage of concurrent licensing is not allowed under Strict enforcement.

For the Node metric, Strict enforcement requires a computer to be on the list of computers that the Policy is “Assigned To:” (aka.the Node list) in order for a launch attempt to proceed. If a node entitlement has been previously assigned to a computer allowing a launch, an offline launch will also be allowed. But if the launch attempt (online) was denied, the computer stores the fact that it is not entitled to use the product and subsequent launch attempts offline will be blocked (i.e. the management policy is strictly enforced).

In all cases, Relaxed enforcement makes no attempt to manage usage when a computer is not connected to the KeyServer. When enforcement is set to None, there is no attempt to enforce a limit on entitlements at any time – even when clients are Online. For both Relaxed and None, offline usage is simply allowed, launch and quit events are recorded, and later sent to the server as “offline” usage events.

The Use-case for No Enforcement of License Entitlement

The unique advantage of applying no enforcement to an entitlement Metric (unlike the “Observe” setting) is that K2 will then measure consumption of the license entitlements by their corresponding metrics. This data then feeds into K2’s Purchasing Dashboard and Compliance reports to measure Effective License Position and reveal optimization opportunities for cost reduction.

Another reason to consider use of no enforcement is if your license agreement for this software product includes “True-up” rights (periodic adjustment of licensing levels to align with consumption). Under this model, the no enforcement setting will permit clients to use more than your current licensing level. Later, at your next True-up cycle with the software publisher/reseller, you can check K2’s Compliance report to determine whether you need to purchase additional licenses.

The distinction of “Online” vs. “Offline”

Keep in mind that not all usage away from your organization’s office is classified as “offline”. If the client computer has an Internet connection from anywhere in the world and Port 19283 is open on your network for UDP traffic to the KeyServer host, a client on the other side of the world can connect. Likewise, “offline” isn’t considered in the traditional sense in this context either – a Client computer can be connected to the Internet, yet unable to reach the KeyServer.

Entitlement Allocation – Policy Assignment

For some Policy Metrics (Node, Socket, Core, PVU, Special), usage of the Policy is only allowed when a computer is on the Policy’s “Computers” list. Computers can either be Assigned to the list manually (by clicking the computer icon and dragging from the Computers window) or Auto-assignment can be enabled, based either on launch attempts (Usage) or discovered installs (Audit). These options are only configurable for Metrics where the “Computers” list is consulted to determine if the policy can be granted (Node, Socket, Core, PVU, Special).

Likewise, for a User Metric, Users can be added manually, or automatically based on Usage only. Users can’t be added by Audit (discovery) since an Audit is directly related to a Computer, and not a User. A single Computer could have multiple Users, or a single User could have multiple Computers – so assigning a User policy based on Audit would not be meaningful. For Concurrent, Lease, and User Lease Metrics, these options are still visible, but cannot be changed – Usage will be burned on while Audit will be burned off. Note that user-based Groups (for Policy Scope settings) must be managed by an external authentication process.

If the Metric is set to “Site” then any Clients within the specified Section and Scope settings have access to the Policy. Thus, a “Site” Policy can be treated as a site license for your entire organization or for a sub-set defined by Section and Scope settings.

Default Actions

Policies have no effect on clients outside of their configured Section or Scope. That is, if the client computer (or user for User Policies) is not in the Section, or if group membership is not satisfied, KeyServer continues checking for other Policies which might apply. If KeyServer does not find any applicable Policies, the software launch is ignored (and permitted to run). See the documentation below on Policy Configuration for Observe and Deny policies.

There are many other Policy settings options that are less commonly used. Learn more about the Policy Details Window.

Gaining Full Visibility of Software Usage throughout your Ecosystem

When software licensing rights for certain products must be limited to less than all of the computers managed by K2-KeyServer, it is a recommended best practice to create Section/Scope limited “Manage” Policies for management and reporting of licensed utilization – and, additionally, to create Universal Observe or Deny Policies to provide visibility or access restrictions outside of the licensed scope of the software products. This is especially important when organizational-wide software license compliance is a goal.

K2 Policy Configuration – Observe Policy & Deny Policy

Start (and end) with the Policy Wizard

Begin Policy construction for an Observe or Deny Policy by right-clicking over the target Product in the Products window and selecting “New Policy…”. If the Product doesn’t appear in the list, refer to the instructions above under: “Find or Create a Product record” and “Optional Cross-platform Product”.

The first pane in the Policy Wizard is for selection of the software product. If you have not selected a product, click the magnifying glass to the right and search the product repository. In the second pane, under “Action”, select “Observe” or “Deny” and then click “Finish”.

Adjusting Policy Settings

The only adjustments to consider for Observe and Deny Policies are to define the population of client computers for the Policy to impact. As described above, this can be narrowed by assigning values for Section and/or Scope to limit the Policy’s impact. Or you may set Section to “Enterprise” and Scope to “Universal” to track usage or deny software on all computers that are not served elsewhere by a Manage Policy for the same Product.

Note that the Section and Scope both limit the computers to which the Policy applies – so be careful to avoid combined restrictions that would make the Policy apply nowhere!

Summary – the Richness and Complexity of Software Licensing

During my years spent writing and guiding the development of the ISO/IEC 19770-3 ITAM Standard for Entitlements, I came to appreciate the richness and complexity of the many different software license metrics that are in common use today. Sassafras has built a correspondingly rich and capable interface for managing, measuring, and ultimately optimizing licensing to achieve software cost control and cost reduction. When SAM practitioners aim for optimization with a capable tool, compliance comes along for the ride.

Tags: , , ,

No comments yet.

Leave a Reply