6.x -> 7.x Important changes
There are many new features and terminology changes in K2 version 7 that are supported by new interface elements in KeyConfigure 7.x. This document describes the most important changes that a 6.x admin should understand in order to take advantage of the new features while avoiding possible confusion stemming from familiarity with a previous version.
New features in version 7 are described with 6.2 as a point of reference and features that are essentially unchanged will not be mentioned here. If you are upgrading from 6.0 or 6.1, it may be necessary to consult older upgrade documentation when features already available in 6.2 are unfamiliar or confusing.
Read this document for an important overview of what to expect, and then follow with the Quick Install & Tour to see the new interface in action. When you are ready to upgrade, read the Major Upgrade document, as it will give a much more detailed description of precisely how your version 6.x configuration will be translated and how to test and clean up the translation before going live with the new version.
Dashboards, all new KeyReporter
In K2 version 7.2, KeyReporter was completely rewritten. It now supports customizable dashboards to give quick insight into important metrics without the need for running reports. Each KeyServer administrator can customize and save their own dashboard layout, choosing from a broad range of widgets. The overall web UI has been modernized and improved. KeyReporter has also been more tightly integrated with KeyServer so for example any reports run in KeyConfigure can be accessed within KeyReporter.
Availability Maps were first added in K2 version 7.2. They allow you to make a graphical map of each Division, which can be used to check what computers are available for login. Since 7.2 we have been adding functionality, such as the ability to show lab hours, show software products installed on computers, and embed links or external html. In 7.4, Availability Maps are able to distinguish between computers that are turned off and computers that are on but with no one logged in. Also we have added a public view of historical availability - i.e. an indication of which hours are busiest. Finally in the "admin view" we have added a "Heat Map" that shows which computers in each division have been logged into the most.
Admin Alerts & Journal
In K2 version 7.4, we have added a Journal of configuration changes and events occurring in KeyServer. Some of these Journal entries get written as a result of an admin taking some action. For example, the Journal could record that the admin named Joe has changed the license limit for a particular Policy. Other entries are the result of automatic processes, and these are also Alerts, to make sure that Admins are aware of them. For example, a failure to export is recorded and displayed as an Alert. For more about this topic, refer to the Admin Alerts & Journal documentation.
User based licensing metrics
We have added direct support for User based licensing metrics. For example, configuring a policy to use a "User" metric will enforce a limit on the number of unique users who can use the policy. In order to use the policy, a user must be on the named user list for that policy (which can be pre-configured or auto-populated until the license limit is reached). To support these license types, there is a new Users database and corresponding window in KeyConfigure. This window shows all users that exist in the database, while the window that has always shown which users have an active connection to KeyServer has been renamed "Connected Clients".
New options for lease license metrics
We have added additional options to Policies that use the Lease or User Lease metrics. A 1 hour "On Hour" lease can be used to enforce Bentley SELECT licensing. This configuration creates a metric where the consumption of the license is measured by the number of computers (or users) that use the license within any hour (e.g. 8:00 - 9:00).
Core, Socket, & PVU licensing
We continue to expand the license metrics that we support. For v7.4 we have added support for Core licensing - which essentially counts the number of cores on each computer instead of simply the number of computers. This is a license metric that is being used more and more by Microsoft. Also, in 126.96.36.199 we have added support for Socket licensing. For Socket licensing, the number of physical CPUs ("Sockets" or "Packages") is counted. PVU, or Processor Value Units, is a metric defined by IBM. In this metric, each different type of computer can be assigned an arbitrary weight, or number of units, which are consumed from a purchased number of units.
K2 version 7.0 introduces a major new feature – Purchase tracking. The focus is on software license purchases, which are actually entitlements for specific rights and conditions. These rights must be managed in accordance with the license terms as documented in purchase records that also demonstrate "proof of ownership". When original purchases, upgrade purchases, expiring entitlements, and upgrade plans are accurately recorded, KeyConfigure will calculate a "bottom line" summary showing how many of the purchased entitlements for each product version are currently valid. The automatic calculation of a "current entitlement position" provides information going well beyond a simple order tracking system which is limited to documenting purchase histories.
The purchase tracking feature also includes archiving for contracts and documentation associated with each purchase so that an audit trail is easily organized and maintained. When the entitlement position summarized from the purchase data is compared to the "policy position" which summarizes management policies, any discrepancies are reconciled in order to easily achieve and demonstrate license compliance.
Products vs programs
In K2 version 7.0 we introduced 'Products'. The addition of a Product database in version 7 makes it easier to correlate purchase records, audits for installed software, and license management policies. A Product record represents the product as it is sold by a software publisher. The product definition lists the programs that make up the product. As in 6.2, it is program files that are discovered on client computers through the audit process and then listed in the programs window. But in 7.0 and later, there is a separate Products window supported by a "knowledge base" that aggregates programs into Product records. The main programs that constitute a Product, those that may need to be managed for license compliance, are classified as main 'Applications'. The auxiliary programs that are typically included in most installations but are not central to functionality are classified as 'Utilities' – Utilities are associated mainly for a reference - usage of Utilities will never be observed or managed.
In version 6 there was no direct reference to Products. Multiple application programs comprising a product could be aggregated and managed as a single entity under a "Suite License", but if this same aggregation was needed for use in another license, it had to be created all over again. In version 6, the aggregation of programs as a Product was not explicitly encoded or given a name, so it was not available to be directly referenced in other license policies or in reports.
Product Recognition Service, PRS
K2 version 7.1 and higher support access to a cloud based Product Recognition Service (PRS) so that product definitions relevant to executable software discovered at your site will automatically populate the Products window. For less common products, a wizard is included to assemble your own Product definitions by choosing the appropriate Application and Utility components from the programs window.
Policies in version 7 are very similar to Licenses in version 6. The main difference is that Policies manage Products while Licenses in version 6 controlled programs. Products consist of a set of programs that are related (sold or licensed as one) and Policies define how to manage those Products. As an example, in order to manage licensing for Microsoft Office in version 6, it was necessary for the License to reference each of the several main Application programs comprising the Office suite. In version 7, the corresponding Manage Policy is configured with a reference to a single Product, "Microsoft Office". The Product definition takes care of aggregating its component programs, so the Policy just references the single Product while the underlying programs are referenced indirectly.
Policies in version 7 also introduce the new capability of supporting a scope limitation that can be used to restrict effects of the Policy to a subset of computers. Before launching a Product, computers within the Scope of a Policy are required to obtain a license allocation, either from this Policy or some other - otherwise the in-scope launch will be denied. But a Policy with a Scope restriction will never deny a Product launch outside of its scope. This behavior is very different from K2 version 6 where a “License with a Group restriction” will always deny launches outside its Group (unless enabled by some other License). The two interfaces look very similar - there is a group field in both the 6.2 and 7.0 details windows in a similar position - but the consequences outside the restriction are quite different. If the 6.2 behavior of denying usage to anyone outside the group is desired, 7.0 configuration requires a second “Deny” policy which will apply to anyone outside of the group scope.
In KeyServer 6.x, programs were either set to Controlled, Logged, Audited, or Ignored. This was a program attribute and applied in all cases to the program. In KeyServer 7.0, the basic behaviors which resulted from each 6.x program action have been separated from the program record and elevated to the Product and Policy level. In version 7, programs do not have an action attribute at all and neither do Products! Instead, many programs are referenced as components, either Application or Utility, of a Product. And some of these Products may be managed by Policies that implement specific management actions.
Depending on its occurrence as a Utility only or as an Application in various Products, a program will be tagged with a Status of 'Utility' or 'Application'. If it is not part of any Product, it is tagged with Status 'Ignored'. Program Status does not directly correspond to the old 6.x "program actions". Program Status cannot be specified directly – it merely summarizes whether and how the program is included in various Products definitions.
Program Status determines which programs will be included in which reports:
A program that is an Application component of at least one Product is tagged with status 'Application' - it will be included in standard Audit reports and all launches and quits within the scope of a managing policy for the Product will be logged for inclusion in usage reports.
launches / quits
A program that is a component of some Product, but is never included in any Product as an Application component is tagged with status 'Utility' - usage of this program will never be observed or managed, and generally it will not appear in any Audit reports either.
A program that is not a component, neither an Application nor a Utility, of any Product is tagged with status 'Ignored' - it will not appear in standard Audit reports and it will not be logged so it can never appear in any usage report.
* as in 6.x, the Audit database includes all programs discovered on client computers along with a "last used time" on each client. By default, Audit reports only include Application programs, but there is a checkbox in the Options pane of the Report Builder window that allows you to Include Utilities and Ignored Programs as well.
The old 6.x ignored behavior for a program simply meant "don't control, don't collect usage info, and don't include in audit reports". The table above shows that this behavior is achieved in 7.x whenever the program is not a component of any Product. The old 6.x audited (but not controlled) behavior simply meant "include in audit reports even if not controlled". In 7.x, this is achieved by including the program in at least one Product as an Application, but not associating any Policies with the Product.
Although the program level 6.x actions are no longer directly available, the familiar program behaviors can be achieved by defining a Product with the correct Application components, and then managing that Product with Policies having appropriate Policy Actions:
- A Policy with Action set to Manage (i.e. a 'Manage Policy') has nearly the same functionality and user interface as the familiar License configuration of version 6 – but with two important changes. A Policy manages a Product instead of a collection of programs and the optional 'group restriction' for a License has been replaced by the optional 'scope restriction' for a Policy.
- Usage logging in version 6 was specified at the program level in order to extend logging to programs that were not already being logged due to a controlling license. In version 7, a Policy with the Action set to Observe (i.e. a 'Observe Policy') is created if needed in order to extend logging beyond the scope of other Policies – an Observe Policy will log usage for all Application components included in its associated Product(s).
- A version 6 License configured with a group restriction will deny any launch attempt outside of the group, but a version 7 Manage Policy configured with a group limited Scope will ignore any launches outside the group. In order to deny (and log) launch attempts that occur where they would otherwise be ignored (i.e. outside the scope of all other Policies), a version 7 Policy with a Deny Action (i.e. a 'Deny policy') for a specified Product can be created.
The translation from the old 6.x programs controlled by a License to a 7.x Product managed by a Policy is straightforward. Assuming the appropriate program(s) from the 6.x license are included as the Application components of a Product, a Manage policy for this Product is configured to mirror the old License configuration. In case the old License had a group restriction, this same group is used to limit the scope of the Policy. Keyed programs within the controlled Product will match old behavior, but to exactly match the old license behavior for unkeyed programs within the Product, a Deny policy may also be needed.
The translation of the old 6.x logged behavior is also fairly simple - just include the program as an Application component in a 7.x Product that is managed by an Observe Policy. Of course an Application launched within the scope of a Manage or Deny policy will already be logged, so Observe policies may seldom be needed. However, in order to simply gather some usage data for a set of programs launched in a scope that is not already being managed, a "synthetic product" can be created consisting of the set of programs, all classified as Applications. Then this "synthetic product" is placed under the management of an Observe policy. Additional flexibility can be gained by restricting the Observe policy to a specified scope.
It is the combination of program Status together with Policy Actions that determines program behavior and this combination can be configured to mimic the old version 6.x behavior. The translation from version 6 to version 7 is carried out automatically by the upgrade installer and it is described fully in the upgrade documentation. The end result is a more flexible interface for specifying how and where products are managed, and consequently, how underlying program behavior will be affected.
Policy Details UI
In addition to the changes described above between 6.x Licenses and 7.x Policies, the Policy Details window has been changed a bit in other ways as well.
- New Enforcement Types - K2 6.x had a checkbox in the Options pane named "Detachable". Turning it on would allow programs under control of the Policy to run even when KeyServer was unreachable. In K2 v7.4 we have removed this checkbox - instead, the "Scope & Action" pane has an option called "Enforcement". The "Strict" option corresponds to turning off the old "Detachable" option. The "Relaxed" option corresponds to turning on the old "Detachable" option. Finally, the "None" option corresponds to turning on the old "Detachable" option as well as the old "Over-limit" checkbox, which has also been removed from this pane in 7.4. The new UI makes it much easier to tell how a policy is being enforced. Enforcement None allows you to configure correct Metrics and Limits, which can be used for reporting, but to never prevent a user from using software. Enforcement Relaxed tries to enforce the policy limit whenever possible, but doesn't prevent use if KeyServer can't be consulted to check the Policy. Enforcement Strict can be used to make every effort to stay under the defined Limit, even at the expense of denying use when KeyServer can't be reached.
- Auto-assign based on Audit - K2 v7.4 has a new feature to add computers to the Node list of a policy based on seeing that the managed product is installed - even if it has never been used. This option is only available for Node, PVU, Core, Socket, and Special Metrics. When enabled, the assignment happens nightly. When a product is seen as installed, the computer is added to the Node list. If a product is uninstalled, and the computer had never generated usage against the policy, the computer is removed from the node list. The 6.x checkbox for "Auto-add up to limit" has also been renamed, to "Auto-assign based on Usage".
For more about these options, refer to the Policy Details documentation.
Keyed vs Un-keyed management
When managing the launches of a particular program, version 7 continues to offer the option of transforming an instance of the program into a "keyed" variant which is then distributed to the intended clients as appropriate. But with the increased management flexibility of 7.x Policies, managing unkeyed variants may be just as effective while avoiding the additional steps required to create a keyed copy. However, the complete and consistent management of unkeyed programs does assume that KeyAccess version 7 has been installed (and remains installed) on all client computers that you wish to manage. Some differences between keyed vs unkeyed management are detailed below along with specifics on which features absolutely require the upgrade of KeyAccess.
Under either KeyServer 6.x or 7.x, the default behavior for "unkeyed" but controlled programs is to allow all launches when offline (or when KeyServer is unreachable), but for keyed programs, offline launches will be denied (unless supported by a checked out key, or cached key from a Node or Lease Policy). In 6.x, the default, "allow launch offline", option could be turned off for individual programs so their behavior when controlled by a license would mimic the offline denial behavior of keyed programs - but in 7.4, there is no such program level option! Instead, the 7.4 Policy is set to 'Enforcement: Relaxed' in order to allow usage offline or when the KeyServer is not available. Likewise to deny usage offline, the 7.4 Policy is set to 'Enforcement: Strict'.
Whenever a program is granted a license from a Manage Policy (during an online connection to KeyServer), the subsequent behavior of an offline launch attempts depends on the details of the Policy. Node lock and Lease policies will have allocated licensing rights to the specific client node so subsequent launches, both online and offline, will be enabled by KeyAccess (but only for a limited time in the lease case). Subsequent launch behavior of a program that previously launched under a Concurrent use policy or Site policy depends on the Enforcement of the Policy - if it is 'Relaxed', offline launches will be allowed, if it is 'Strict', they won't.
Note: as soon as a pre 7.x KeyAccess has successfully run an unkeyed managed program while connected to KeyServer 7.x, all subsequent offline launches will be allowed to run offline regardless of the Enforcement setting in the Policy details!– upgrade clients to version 7.x if you need to deny offline launches of unkeyed programs (e.g. for Strict Enforcement of a concurrent use Policy on computers that may go offline).
KeyAccess Client Compatibility
The new KeyAccess 7.x is "backwards compatible" – it can be used with older versions of KeyServer. This means you can conveniently upgrade all clients to version 7.x before upgrading the KeyServer itself so that all 7.x features will be available as soon as the KeyServer upgrade is completed. The documentation below summarizes of how old client versions react to various KeyServer 7.x configurations – but instead of spending time reading the details or spending time trouble shooting an old client's puzzling behavior, it is always best to just upgrade all clients to 7.x!
Even with a mix of KeyAccess client versions, however, the behavior of a keyed program is unchanged by the KeyServer upgrade and is easy to predict : the keyed program will only run from within the scope of a Manage Policy and only after getting a valid "key". But management of unkeyed programs on clients prior to 188.8.131.52 will fail as soon as the KeyServer is upgraded to version 7! – unkeyed programs will simply be allowed to run. Also, logging of unkeyed program usage will fail on KeyAccess versions prior to 184.108.40.206 and pre-7.x KeyAccess versions are unable to deny offline launches of unkeyed software (as mentioned above).
The launch of an unkeyed program outside the scope of all relevant Policies will simply be ignored by all versions of KeyAccess when connecting to KeyServer 7 (unlike a keyed program, which won't launch) . But the behavior of an unkeyed program that is launched within some Policy's scope will vary depending on the KeyAccess version:
in Scope behavior
in Scope behavior
in Scope behavior
|220.127.116.11 - 7.x||manage (grant or deny)||observe||deny|
|18.104.22.168 - 22.214.171.124||manage (grant or deny) *||unkeyed ignored||deny|
|pre-126.96.36.199||unkeyed ignored||unkeyed ignored||unkeyed ignored|
* if a Manage Policy is set to a limit of 0, the 7.x client will properly deny launches but versions 188.8.131.52 and older will ignore instead. (Note: when upgrading from 6.x, any License with limit set to "0" will be converted in 7.0 to a Deny policy, therefore preserving the former behavior even for clients 6.1.2 or better).
One of the main improvements in going from 6.x License control to 7.x Policy management is due to the way a Group restriction for a 6.2 License (that managed usage within the Group while prohibiting usage outside the Group) is transformed into a Scope restriction for a Policy (which manages usage within the Scope while ignoring usage outside the Scope). Since this is new functionality, management of unkeyed programs within the scope of the various policy types is only fully supported by KeyAccess 184.108.40.206 and higher (as documented in the chart above).
In K2 version 6.x, Audit reports were exponentially slower as the Audit database grew larger. This made audit reports painfully slow at very large sites. In version 7, Audit reports are many times faster, especially for large Audit databases. If 6.x data was being exported to a high performance database server only because Audit reports ran too slowly, this may no longer be necessary after upgrading to 7.x.
Note: K2 version 6.x let you specify programs to include in audit reports even though you were not interested in logging or controlling, but in version 7.x, standard audit reports include only programs that are an Application component of a product. After an upgrade, the set of programs displayed in standard Audit reports may be different but, if necessary, you can mimic the old behavior by managing product definitions. And there is a checkbox in the Options pane of the Report Builder that allows you to Include Utilities and Ignored Programs in Audit reports.
In previous versions of K2, administrative access to KeyServer was controlled solely by Accounts defined within the KeyServer itself. In version 7.x, KeyServer management accounts can be linked to a standard enterprise authentication service so the account passwords are managed independently from the KeyServer service.
In K2 version 7.3, we have added the concept of "Sections". Sections are a way to partition a single KeyServer in order to accomplish Federated Management. Section Manager accounts have limited visibility and configuration rights into only certain Computers and their relevant Policies and Purchases. For more about what Sections do and how to use them, refer to the Sections documentation.
Improved Access Control
Support for controlling admin access to specific objects in K2 has been improved in v7.3. The basic functionality has been made more flexible, and better defaults have been set up to avoid manual overrides in more cases. Access Control Lists, or ACLs are also important to making Section Administrators easier to configure. When upgrading from an earlier version, Access permissions are carried over from the previous configuration, but you can probably simplify configuration by changing settings after upgrade. Contact Sassafras tech support if you want help with this.
K2 is now able to audit and track usage of Java programs. In order to use this functionality, both KeyServer and KeyAccess must be version 7.3 or higher. Java programs appear just like any other programs, in the Programs window of KeyConfigure. They can be added to Products and will then appear in Audit reports, and those Products can have Observer or Manage Policies - just like any other Products. Note that since KeyServer might be supporting some 7.3 clients and also some older e.g. 7.2 clients, it will "see" Java programs only on the clients that are 7.3 and newer.
New Program IDs
K2 7.3 introduces an enhanced way of uniquely identifying programs. Some program IDs are unaffected, but other programs will have a different ID when seen by a 7.3 client vs a pre-7.3 client. This change is important for supporting Java applications, but also can help improve recognition of non-java executables. KeyServer and KeyConfigure automate the addition of new program IDs to existing products in order to ensure a smooth upgrade that doesn't require a lot of manual reconfiguration.
Along with the obvious addition of the new main windows to display Purchase and Product records, the program window has been deprecated to a lower level of importance – the main focus is now Products with the component programs playing a supporting role. The interface for transforming a program into a "keyed" variant has been moved to a File menu item. A Tasks menu lets you bring up Wizards for the creation of new Product, Policy, and Purchase records, along with a wizard to help reconcile purchase records against management policies. These tasks can also be invoked from various context menus when appropriate.
New icons and color conventions are introduced to help distinguish the new object types. A few of the 6.2 icons have been changed for better legibility even though representing a familiar object from 6.x. For a detailed list of icons, see the Icons documentation and for definitions of the vocabulary used in 7.x, see the Glossary documentation.
Upgrade Process, 6.x -> 7.x
While the translation from version 6 to version 7 is carried out automatically by the 7.x installer, it is still important to prepare first and to follow the Upgrade from 6.x to 7.x documentation carefully. Assuming KeyAccess clients are not too old (as documented above), the 7.x installer will achieve the transition from 6.x to 7.x without changing behavior. But there is little point in upgrading if you leave it at that!
The combination of well defined Products together with carefully configured Policy Actions can mimic the old version 6.x functionality, but the real power of K2 version 7 comes from the addition of Purchase tracking and new Policy options that enhance management while supporting compliance reconciliation. To quickly learn about the new functionality of K2 version 7.x, the Getting Started tour has been designed to let you set up a playground of client, server, and admin components all running on the same computer so you can safely experiment with all the new features. After gaining some familiarity with 7.x, follow the detailed upgrade documentation to transform from 6.x. After running the installer, several cleanup tasks may be recommended in order to better organize management Policies so they make best use of the new Product and Purchase data.