Policy Details Window

The policy details window displays the full configuration of a particular policy. For a general description of what a policy is, see the Policies Window Documentation.

The Name field in the detail window is used in the Policies Window to identify the policy. In the details window, you can customize the name in any way that is useful. There are eight panes containing further configuration options. The default view exposes only three of the eight panes – Scope & Action, Information, Products – other panes can be exposed by clicking the small icons to the right of the name.

Scope & Action pane

The configurations in this pane are the basis of what computers or users the policy might apply to, and what actions and enforcements might take place. It is important to ensure this is consistent with the Rights and Conditions for any Purchase that is also linked to the targeted Product. If not, compliance reporting will flag the discrepancies.

The illustrated configuration above pertains to all computers, because all Sections (i.e. Enterprise) are included and there is no restriction on Scope (i.e. Universal). For any program belonging to a relevant Product (listed in the Products pane), the configured Action will be applied whenever the program is launched on any computer.

When creating a new policy under the root Administrative account, the Section will default to Enterprise as illustrated above. Assuming other Sections have been defined (in the Computers window), entering a specific Section instead of Enterprise will restrict the influence of the policy to that subset of computers. In fact, when creating a policy using a Section Manager account, the restriction to the corresponding section is enforced and will be entered automatically.

A policy can also be restricted using the Scope field – enter a specific Group name in place of the default scope, Universal. As a simple example, suppose there is a computer Division named "lab_126". A corresponding group can be easily created by dragging this division (from the Computers window) into the Groups window - let's name the newly defined group "LAB_126". Now dragging this group (or typing the name ) into the Scope field will restrict the policy's effect to just the computers in the LAB_126 group (which in this case simply means the lab_126 division).

In the simple case of a single Division used as a scope, there is a shortcut – just type "@lab_1" directly into the scope field. You can also use the prefix "!" to indicate negation or the compliment, so the scope of "!@lab_1" will apply only to computers not in the lab_1 division.

A set of computers that have been assigned a Tag (e.g. "kiosk") can also be referenced for use as a Scope – use "#" as a prefix to the tag name (e.g. "#kiosk").

If you are using the Active Directory Client Authentication option, you can also specify an OU directly in the scope field, using the syntax "ou=myou"

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!

Action

Having specified which computers the policy should effect (i.e. Section and Scope), the intended behavior is specified by the Action: Manage, Observe, or Deny. Regardless of which action is chosen, whenever a program launch is handled by the policy, usage information is recorded for the program launch, the product use, and the policy grant – this data is the basis for the program, product, and policy Usage reports. When the Action is set to Observe, the policy has no further effect other than logging use. Observe is the default action for our automatic policy wizard, and easily created in the Manage screen of our Web UI. When the action is set to Deny, however, then the client agent, KeyAccess, is instructed to block the launch – in this case the "usage" log will record the denial.

Note: Only Observe policies are available in the LabSight tier of the Sassafras Server product. Conversely, Observe policies are available but not very useful in the KeySight tier as they will cause you to fill your license usage quickly. Only the AllSight tier fully unlocks the power of policy management.

When a product is governed by multiple policies, there is a configurable order (in the Product Details window) in which KeyServer will attempt to find a relevant policy. Note however, that Management policies always take precedence over Observe and Deny. If a client is in the scope of any Management policy for a product, then an attempt to launch an Application Component of the product will always result in either a license grant or license deny. Observe and Deny policies for a product will have no effect unless the computer using the product is out of scope for all Managment policies referencing the product – and furthermore, of course, each Observe or Deny policy has effect only within its scope.

As an example of how policy ordering might be applied, consider two Management policies for a product, each configured with a different division as scope within a Section containing ten divisions. Also assume there is an Observe policy for the same product configured with Universal scope for the same Section. Usage will then be logged in every division (within the Section), either due to the two management polices scoped to specific divisions or due to the Observe policy which covers the other divisions. In the case of the Enterprise Section, this means usage for the product will be logged everywhere while being managed in the two specific divisions.

Entitlement expiration date can be used to set a date on which the policy will no longer be active. This means usage will not be recorded or blocked or managed based on the policy configuration. This does not mean that the software will be implicitly blocked without an active Deny policy if a Manage policy expires. You can click the bell icon to set a reminder schedule for the admin email to be notified of the upcoming expiration.

Policy is Enabled - Un-checking this box causes the policy to no longer have an effect on any clients. This is similar to deleting the policy entirely, but allows a historical record of how the policy was configured, as well as allowing usage reports to continue to include the policy.

Metric

This is only shown for the Manage Action. There are 9 choices of Metric that correspond to common license types. [ Note: the Metric specified in a policy must accurately correspond to the licensing rights that were purchased. When these rights, including the Metric, are accurately recorded in KeyServer's Purchase database, it will then be easy to reconcile purchased Entitlements against Managment Policies. ] The interface and behavior of each are described below:

Site - policies with this metric have no counted limit. You may want to define a Scope for a Site License if the “Site” defined in your license purchase is not actually your entire site. Controlling a product with this metric is almost equivalent to simply logging the product. A Site policy may be configured so that clients cannot use the associated product unless they are connected to the KeyServer (Enforcement: Strict), whereas Products with Observe policies can always run.

Concurrent - policies with this metric have a restriction on how many can be used at any given time (concurrently). Another common name for this license type is a “Floating License”. If the limit is 5, then only 5 copies of the license can be used at once, even though 20 distinct computers may have used the license at some point in the past. When this license type is selected, the License Limit specifies the concurrent use limit. The expansion triangle button to the far right of the Metric drop down becomes active. Clicking it will expand the section to reveal additional options for defining multiple pools (Groups of Users or Computers), as well as Schedules.

For more details about this, refer to the Scheduled Policy Allocation documentation.

Lease - policies with this metric are somewhere between Node and Concurrent. As long as there is a license available, anyone can be issued a license - but then they will continue to hold the license for some period of time after actively using it. However, once that period of time passes, if they have not used the license again, it will be automatically revoked. So one way to think of it is as an Auto-Add Node Policy which automatically revokes licenses when computers stop making use of them for a period of time. Another way to think of it is as a Concurrent Policy where the license is floating between computers, but stays associated with each computer for longer than the actual program usage.

the Renewal Period specifies how long a lease lasts for. Each time the license is actively used to allow a program launch, the lease is automatically extended. It will extend for the configured time period beyond when the license stops being actively used. The On Hour checkbox specifies that the lease should always expire on an hour boundary - the last hour boundary that would normally lie within the Renewal Period. For example, quitting a program with a 2 hour Lease Policy at 1:45 would normally extend the lease until 3:45, but with "On Hour" enabled, the lease instead ends at 3:00. This option is most useful with a 1 hour Renewal Period, to enforce Bentley SELECT licensing.The Browse Period specifies a short initial lease duration - if the program is quit within the Browse Period, the license is only held for the Browse Period, and not for the full Renewal Period. This can be used to avoid counting accidental launches (and immediate quits) against the license.

You can simulate what the maximum allocation would have been if an existing policy had already been a lease policy by using the Lease Simulator (LIC) report.

Node - policies with this metric are only allowed to be used on a specified list of computers, regardless of how many computers are actually running the product at any given time. When this metric is selected, the License Limit field lets you configure the license limit: i.e... the maximum size of the Computer List.

Caution: if you specify a Scope for a Node Policy, and the Computer List includes a node that cannot possibly satisfy the group requirement, then the license locked to this node will subtract from the license limit with no possibility of actually being used! Before specifying a Scope remove any existing members of the Computer List that don't qualify as group members.

User - policies with this metric are only allowed to be used by a specified list of Users, regardless of how many computers they are installed on or where the product is running at any given time. This metric is very similar to Node except that it counts users instead of computers. When a policy is configured to use this metric, the License Limit field lets you configure the license limit: i.e... the maximum size of the Licensed User List. An extra button is displayed in the Information pane - Licensed Users will show which users have currently been allocated a license, and are therefore able to use this policy. This list can be configured manually or automatically.

Caution: if you specify a Scope for a User Policy, and the Licensed User List includes a user who cannot possibly satisfy the group requirement, then the license locked to this user will subtract from the license limit with no possibility of actually being used! Before specifying a Scope remove any existing members of the Licensed User List who don't qualify as group members.

Note: you can create Groups of users and then use the Concurrent Metric to create a floating user based allocation as well and remain compliant if your number of users does not exceed your number of seats. This would not be the ideal method, but could have uses outside of a strictly user based license.

User Lease - policies with this metric are only allowed to be used by a specified list of users, and those users automatically return a license some period of time after they stop using the software. This metric is just like the regular (computer based) Lease metric, except that users are counted instead of computers.

PVU (Processor Value Unit) - policies with this metric are only allowed to be used on a specified list of computers, regardless of how many computers are actually running the product at any given time. Each computer uses a number of entitlements equal to the Processor Value Unit of that computer. In order for the policy to be used on a computer, sufficient entitlements must be available or already assigned to that computer. The PVU defaults to 100, and can be changed in the editable PVU field in the computer details window.

Core - policies with this metric are only allowed to be used on a specified list of computers, regardless of how many computers are actually running the product at any given time. Each computer uses a number of entitlements based on the CPU cores on that computer. In order for the policy to be used on a computer, sufficient entitlements must be available or already assigned to that computer. The formula for determining the number of entitlements is defined by Microsoft. The following table from Microsoft shows the "core factor" applied to each processor type. The number of entitlements for each type is the number of cores times the core factor:

Processor TypeCore Factor
All processors not mentioned below1
AMD 31XX, 32XX, 41XX, 42XX, 61XX, 62XX Series Processors with 6 or more cores0.75
Single Core Processors4
Dual Core Processors2
Simply stated, the entitlements required equals the number of Cores on the computer, but no less than 4. For certain computers with AMD processors of 6 or more cores, 9 entitlements are required for each 12 processor cores.

Socket - policies with this metric are only allowed to be used on a specified list of computers, regardless of how many computers are actually running the product at any given time. Each computer uses a number of entitlements based on the CPU sockets on that computer. The number of sockets is the number of physical CPUs or “packages” in the computer. Often this is a smaller number than the number of cores, since each CPU might have multiple cores. In order for the policy to be used on a computer, sufficient entitlements must be available or already assigned to that computer. Note: this metric was added in version 7.4.0.2. If your KeyServer or KeyConfigure is an earlier 7.4 version you will not see this option. Likewise, in order to properly count sockets, your client computers will need to use KeyAccess 7.4.0.2 or higher.

Special - policies with this metric are only allowed to be used on a specified list of computers, regardless of how many computers are actually running the product at any given time. Each computer uses a number of entitlements determined by a custom formula based on attributes of the computer. In order for the policy to be used on a computer, sufficient entitlements must be available or already assigned to that computer. The custom formula uses a special syntax that includes arithmetic and logical operators in combination to arrive at a numerical entitlement value. For further information, contact Sassafras Software Support.

Auto-assign based on: (Usage, Audits)

For some Policy Metrics (Node, Core, PVU, Special), usage of the Policy is only allowed when a computer is on the Node List for the policy. Computers can either be Assigned to the node 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 Node List is consulted to determine if the policy can be granted (Node, 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 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.

Enabling Auto-assign based on: Usage will configure KeyServer to add a computer attempting the use of a managed product to the node list – or else block the launch if the Entitlement count is already at the limit. This happens when a client attempts a launch, so obviously this automatic action can only occur when a computer is online. A computer assigned by usage will remain on the node list until removed manually or until removed by the "Auto-assign based on: Audit" option. (Note this can apply to Users instead of Computers, in the case of the User metric)

Enabling Auto-assign based on: Audit will configure KeyServer to run an update action every night that compares its most up-to-date audit information with the node lists for all node based policies. Based on the most recent audit data of product installs, KeyServer attempts to add or remove computers from a policy node list in order to conform to the products that are actually installed on each computer. With Strict Enforcement, this automatic re-assignment will of course halt whenever an Entitlement limit has been reached. A launch attempt on a computer not on the node list for a policy (i.e. not having been assigned a license entitlement) will be blocked – unless of course some other policy has, or is able to, grant an entitlement.

Enforcement:

This is only shown for the Manage Action. When a client computer has an active connection to the KeyServer, a particular launch attempt will either be blocked or allowed to proceed depending in a fairly obvious way on whether any entitlements are available (without exceeding the limit) and on the particular license Metric.

However, if the client computer is not able to connect to KeyServer, the client must decide on its own whether to allow or deny any particular use of a program. When a client makes use of a policy online (either being granted or denied a launch), the policy rules are remembered by the client, so it can remember the basic rules for use when offline. For certain license types where a license has a well defined time when it is valid (Node, User, Lease, User Lease), the KeyAccess client can "know" that it holds a license, and it will allow use when offline because of this knowledge.

Conversely, the client might know that it does NOT have a node license (it was denied while online), or it might know that the program being run is controlled by a Concurrent License - and only the KeyServer could determine whether a license is currently available. In these cases when the client does NOT have a license already cached, the Enforcment setting is used to determine whether the launch should be allowed.

Enforcement: Strict will prevent license Assignments from exceeding the specified number of Entitlements. Client computers are instructed to not allow a launch unless the client has, or can obtain, an assigned entitlement.

As common examples of client behavior, Concurrent Use and Node locked metrics are explained below. The behavior for other metrics is similar to one of these cases.

For the Concurrent metric, license entitlements are assigned at program launch up to (but not to exceed) the specified limit. When enforcement is strict, client computers must maintain a connection to KeyServer througout use of the policy – "offline usage" is not allowed because without an active connection, there is no way to know the "current" usage count. Note: you can inspect the list of current users of the policy by clicking the "Assigned to:" icon. The "Assigned to:" list is also available from the policy's Information pane. In that pane, the list is called "Active Clients".

For the Node metric, Strict enforcement means a computer must be on the list of computers that the Policy is "Assigned To:" (aka.the Node list) in order for a launch attempt to proceed – the number of computers listed cannot exceed the Entitlements count. 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 – a subsequent launch attempt offline will be blocked (i.e. the management policy is strictly enforced). Both online and offline, the usage events (the launch or launch attempt and the quit) will be recorded so the information is available for use in reports, either immediatly or after the client next returns online.

Enforcement: Relaxed is a modification of the strict enforcement that makes no attempt to control usage when a computer is not connected to the KeyServer - "offline" launches are simply allowed. There is no assurance that license limits will be honored due to possible offline usage, and yet for "online" usage, the limit will be enforced. Any usage offline will be logged on the client and uploaded at the next connection for use in reports, which therefore might show that the entitlement limit was exceeded.

Enforcement: None has the same behavior as Enforcement:Relaxed when a client is offline - all offline use will be allowed. Furthermore, with Enforcement:None, the KeyServer makes no attempt to enforce a limit on entitlements even when clients are Online. Entitlements are measured according to the Policy Metric, but the count of Entitlements is allowed to exceed the configured Limit.

Information Pane

     Policy Information Pane

This pane shows some basic information about the policy.

Folder and Tags can be used to organize and color code your purchases for easy filtering and reference in the Policies window.

Both Purchases and Policies can have a Cost Center. This field is used so that Reconciliation between Purchases and Policies can be done either for your site as a whole, or just within a specific subset (a Cost Center). There is a drop down menu which will show values which have already been used for Cost Center, but in addition, the text can also be modified in order to enter a new Cost Center.

Contract is a text field to specify which contract is applicable to this Policy. Contracts may also be specified in Purchase Details, and any that have been input previously will show in the drop down menu.
URL can be filled in with the website of the software this policy is controlling.
Entitlement: For a policy that is set to a specific section, turning this checkbox on will look not only for purchases of the same product within that section, but also enterprise purchases as well. This only affects the calculation and comparison that is made in the Reconcile UI.
Active Clients shows a list of users who are actively using the license (are running programs which require the license).
Computers shows a list of computers which have licenses for the policy allocated (for Node and Lease Policies), or a list of computers that have used the license at some point in the past (for all other metrics).

History

     Policy History

Clicking the History button in the lower corner will open another window with the historic changes to this policy. This includes things like metric and seat count so you can view the changes made to enforcement over time. Like other windows you can sort by any of the columns to more easily see all events of a certain type.

Products Pane

This pane contains a list of Products controlled by this policy. You can double-click on any of the products to see the full product details. Products can be dragged into this list in order to bring them under control of the policy. Generally speaking, aggregation of multiple programs into a "suite" will occur in the Product record, and each Policy will control just a single Product.

One historic reason to have two products controlled by a policy is when an earlier version of a product has been purchased, then upgraded to a newer version. The policy may then be configured to control both versions of the product, in order to allow the older version to continue to run (so that it will not need to be immediately upgraded). This can be useful for perpetual entitlements with specific upgrade or downgrade rights. For subscriptions, it is usually best to reference the Family Product. These special products contain all versions of a product family, and will update automatically from our system as new versions come out, so editing your Products or Policies to keep current is no longer required.

If a policy does control more than one product, one the products listed in this pane will be displayed in bold. The product in bold is the “Primary Product” for the policy. When products are reconciled, KeyConfigure only looks at policies where the product being reconciled is the Primary Product. Note that usage on the policy by secondary products is counted in the reconciliation. This means you can link a Purchase to a Product for Windows which is in turn in a Policy as the Primary but also has the Mac product as a secondary, and both are considered when reconciling the cross platform Purchase. When you associate two products with a policy, KeyConfigure will choose one which it will make the Primary Product. If the products have release dates, the more recent one is set to the Primary. You can manually change which is the Primary Product by right-clicking a product that is not in bold and selecting “Set Primary Product”.

Portable Pane

The settings in this pane are only available for Control Policies. These settings configure the maximum checkout time limit for a Portable key, and the portable limits/options. By default, policies are not portable. You must explicitly configure a time limit for each new policy in order to activate the Portable feature.

Policies enable usage for computers with a network connection. Without a network connection, the default behavior for unkeyed managed programs is to allow offline launches and then report usage at the next connection. Keyed programs, however, generally cannot launch offline. 6.2 and higher versions of KeyAccess will cache the appropriate key when they know they have a Lease or Node policy, and will continue to allow launches offline. However, earlier versions of KeyAccess, or newer versions of KeyAccess using Site or Concurrent Policies will not have a key, so the only way for them to use a keyed program offline is for the user to explicitly run KeyCheckout before leaving the network in order to "checkout a key" for a specified period of offline usage time.

The option to "key" a managed program adds a level of security and piracy prevention to the policy. When portability is enabled for a keyed program, the strength of this security is weakened more or less depending on the options checked in the Portable pane. The default, "Use strong calculation of current time", is intended to prevent a user from extending the checkout time by changing their system clock. The other options are designed to make it more or less difficult to duplicate a checked out key onto a second computer.

Idle Pane

The settings in this pane are only available for Manage Policies. They allow you to set idle time (background warning) settings for programs in products controlled by this policy. Note these are based on the global idle time set in General Settings. Setting a nonzero value here sets a silent counter that starts on a computer using the license when all programs associated with that license are in the background. If the time limit is reached in this state the user is warned or licenses are reclaimed as you specify here. Note that after the license is reclaimed the user is reminded a few times before the programs are shut down (though the license is available to others as of the timer expiration), so if you have set warn 3x then quit the user can effectively see what appears to be more than three warnings.

The "When forcing Quit, terminate without allowing changes to be saved" option will bypass the usual warning dialogs and simply quit the program immediately. It can quit programs without allowing users to save their work, so it should be used only in extreme cases.

Options Pane

Policy Options

The settings in this pane are only available for Manage Policies.

Custom Message Pane

Policy Custom Messages

For Manage Policies, this pane allows you to configure a custom message to be displayed on client computers when the policy is used.
On Grant means the message is displayed when KeyServer allows the application to be launched. You can additionally choose if this message will be shown Every Launch or just once for that user session, and if it is Suppressible meaning the user can choose to not see it again, even if you have set it to Every Launch.
On Queue means the message is displayed when there are no available seats and the request is added to the queue. This will be in addition to the normal alert of entering a queue for the application.

You cannot set a Policy message On Deny, but you can set a Deny message for each program in the product managed by the Deny policy. See Program Details for similar documentation describing custom messages attached to program launches (as opposed to Policy usage). Note: when there is an On Grant message defined both in Policy Details and also in the Program Details (for a program in the relevant product), only the Program message will be displayed.

The following macros may be placed in the custom message, and KeyAccess will replace them with the appropriate values:

^a
name of the currently running program
^d
date on active KeyServer
^D
date on local (KeyAccess) computer
^n
network name of active KeyServer
^t
time on active KeyServer, shown in local (KeyAccess) time zone
^T
time on local (KeyAccess) computer
^u
name of user
^w
name of program user is waiting for, if any
^^
single caret ("^")

Notes Pane

This pane contains a single item, which is a free-form text field. You can use it for any information you want. It can be seen here in the KeyConfigure interface, and can also be used in custom reports.