Policy Configuration Basics

Any organization using KeyServer has a powerful tool for learning how and where computers and software are being used. Using KeyServer, policies can be configured which specify how product usage should be handled – ignored, denied, observed, or actively managed. By setting up such policies, you will be able to understand usage patterns and make decisions about renewing subscriptions and re-deploying licenses.

This post describes how a KeyServer Administrator can gather Program Usage data, starting with the most basic means of recording launches and quits, the Observe Policy. It also looks at the configuration of active license control by use of Manage and Deny Policies.

Observe Policies

Once the KeyServer client (KeyAccess) is installed on an organization’s computers, the Products Window in the KeyServer Administrator’s Program (KeyConfigure) will reflect the names of the Software installed on client computers. The KeyServer Administrator can then create Policies for those Products, which allow for control and tracking of software usage.

Policies set to the Observe action impose no restrictions on access to the associated software, and are the simplest to set up. Since Observe Policies allow clients to run the associated software at any time, either on- or off-net, they are useful for tracking any Freeware, Utilities, Browsers, etc. the site wants to track rather than ignore.

The launches and quits of Observed programs are collected by KeyServer and subsequently will appear in any number of extensive and highly-configureable Usage Reports.

The Observe Policy shown here will collect usage (launches/quits) of Version 63 of Chrome on any client computer, and will never block usage.

A simple observe policy


Observe Policies can be Universal, or they can be Scoped to a group, thus allowing the Administrator to “log” usage of a given Program or Product on some machines, while ignoring it on others. In the example below, KeyServer will record data for machines in the “Chrome Users” Group but if no other policies exist, usage will be entirely ignored (and permitted) on any launches on computers not in that group.

Using a group to apply a scope


Deny Policies

When a site wants to block some (or all) client access to a particular piece of software they should use a Manage Policy and set the Action to Deny.

Deny Policies block all launches of the software in question on all in-scope clients, unless a there is a separate Manage or Observe policy that can grant access.

A Deny Policy


The standard message associated with a denied Program is shown here, but the text seen by the user is customizable at the Program level:


Deny Policies can also be Scoped, and can therefore be used in combination with either Manage or Observe Policies (see “In Combination”, below).

Manage Policies

When software needs to be actively controlled, Policy Action = Manage should be used, and the appropriate metric (Site, Node, Concurrent, etc) specified along with any other Policy Options that may apply. If the Purchases Window has a record for the Product in question the “Rights and Condition” pane of the Purchase Details Window is often a good way to see which metric is best to use.

A Manage Policy


A Site Policy for example (as above) is similar in many ways to an Observe Policy but differs in that current Usage totals are reflected in the Policies Window, allowing the Administrator to actively check on current usage. Manage policies have an “Enforcement” setting of Strict/Relaxed/None. The notion of Enforcement is unique to Manage Policies, so the pulldown selector in question is not available when the policy is set to Observe or Deny.

The various metrics for Manage Policies are discussed in the Policy Details Documentation.

Policies In Combination, and the importance of Scope

The ability to associate a given Product with multiple Policies along with the ability to “Scope” a policy to a group (or groups) offers extremely fine-grained access control, and while this can be complex if required, some of the most common combinations are:

To record all usage of a Program/Product:

Use a Universal Observe or a Site Manage Policy. All usage is permitted and recorded, on all KeyServer clients. We recommend Observe policies for freeware and Site Manage policies for purchased software.

To record use of a Product within a group, while permitting/ignoring launches outside that group:

Use an Observe or a Manage Policy scoped to the group. Usage within the group is permitted, subject to the policy’s settings. Usage outside the group is always allowed/ignored, (unless additional policies are added, as below).

To allow access within a group but deny launches outside the group:

Use an Observe or Manage Policy scoped to the group, and a Universal Deny Policy. Usage within the group is permitted and recorded, subject to the policy’s settings. Usage outside the group is blocked. Note that with multiple policies for a product, a precedence can be set amongst the policies – however, Manage Policies are always higher precedence than Observe, which in turn are higher precedence than Deny.

Two policies for a single product
(click to enlarge)



Even a basic inspection of the interrelationship between Policy Action, Enforcement and Scope should make it clear that Policy Management can be extremely simple but that there are also a very large number of applicable real-world examples that might need to be addressed. If you have any questions about combining the various options into a cohesive and uniform configuration, please feel free to contact Sassafras Tech Support.

No comments yet.

Leave a Reply