K2 includes a Product Recognition Service (PRS) which automatically analyzes the software discovered on computers within your organization and provides relevant product details for use in license management, software optimization, and cost reduction. While the PRS recognition database is constantly evolving to keep up with new product releases and uncommon discoveries, you are never forced to wait for Sassafras to publish a particular product definition. Here we will guide you through creation of your own custom product definition using the New Product Wizard.
Ultimately, you want to define a Product that corresponds to what you have actually purchased. Product details include a number of fairly straightforward properties such as Name, Version, Publisher, and Release Date. But the correct assignment of appropriate program files to the Product definition can be more subtle. There are two main aspects of adding programs to Products. Of course, you want to include the correct programs, but also you should take care to include only the appropriate versions of these programs.
Applications and Utilities
Software Products are sometimes complex and can include many executables. K2 divides these executables into two categories: Applications and Utilities. Even when you install what you think of as a single program (e.g. Microsoft Word), you may end up with hundreds of new executables on your hard drive. Most of these are Utilities, like a Help program, an Uninstaller, a Crash Reporter, a File Conversion utility, a Smiley helper, etc. Applications, on the other hand, are the “main” programs, i.e. the reason you bought the product. When you use the product on your computer, it’s an Application that you will explicitly launch. Utilities add to product functionality, but are rarely used independently. Products in K2 can contain both Applications and Utilities, but K2 only tracks usage for Product components designated as Applications. Standard Product Audit reports focus on these same Application components.
Versions and Variants
All versions of the “same” Application are recognized by K2 as being members of the same program Family. As bugs are found and fixed, it is common for a given release of a Product to be updated with multiple minor revisions of the main Application components (i.e., 6.0.1, 6.0.2, etc). When a program is first discovered by K2, and is not yet part of a Product, the KeyConfigure Programs window will display a single “Variant” for the entire program family. You can change the “Variant Mask” so that the program family is split into several distinct variants, each one corresponding to a “Major Version” of the Product to which the program belongs. For example, consider a single program family with 4 versions: 6.1.0, 6.8.0, 7.0.0, 7.3.0. Typically these may come from two distinct Product releases (major Product versions 6 and 7), so we need just two program variants, 6.x and 7.x. We can adjust the variant mask so the family is “split to one decimal” and these will then display separately in the programs window.
A Simple Example
Now let’s look at a simple example of using the New Product Wizard to create a new definition. Imagine we want to create a product definition for TeamViewer 6 (note though that this is merely an example – there is already a “standard” definition for TeamViewer 6 in PRS). First off, here’s how TeamViewer 6 appears in the Windows Start menu:
The Start menu includes 6 in its label, and this matches how the Product is released (version 5, 6, 7, etc). So we expect to find a version 6 of the teamviewer executable program and we will want to associate it with our new product definition. Let’s get started – in KeyConfigure, select “New Product…” from the Tasks menu:
This brings up the wizard. On the first screen we will fill in as many properties as we want. Release Date and Upgrade From (which you’ll see later) are both very useful when you start using K2 to record Purchases of Upgrades, but we can skip over these fields for now. The Pre-Seeded values in the Category drop-down come from the UNSPSC categorization standard – but you can type any text that you might find useful for associating Products that have similar functionality.
After clicking Next, we are prompted to choose the Applications associated with the Product.
We could drag them from the programs window but notice the magnifying glass icon – clicking that will give us a Find Program window.
After typing “TeamViewer” in the Variant Name field and clicking Apply, we see the matching programs. The first two are clearly “Utilities”. The third one is the Application, but notice that the Variant column shows “all…” meaning that all versions of the program are currently combined in a single Variant. The wizard will adjust the variant mask to help us select just the versions we want when we drag it from this Find window into the program listing box in the wizard – click Next to see the following screen where the variants are split out to the first decimal.
Note that the wizard has put the checkmark next to “9.x”. This is selected by default simply because it is the highest known version. But instead, we will select “6.x”. Click through the last 2 screens – we won’t specify an earlier version of the Product. When we leave the Wizard, we see the new Product Details Window.
Now with the resulting Product Details window displayed, the red bar along the top indicates that this window must be saved. Once we save, we’re done – we can now report on Audits of this Product, record Purchases, and create Policies to track or control usage. There is one last optional step we could take. Remember the two Utilities we saw that belong to TeamViewer? You can add these (using the Product Details window) to the definition as “Utilities” rather than Applications. This will record the fact that they are part of this product so you will never need to wonder if they’re an important Application in some other Product. But usage for utilities is not tracked and they will not appear as detail lines in the standard Product audit reports.
In our TeamViewer example, finding the necessary program was easy – we just searched for the expected name. Sometimes however, Applications will have a different name than you expect, so they will be harder to find. If we don’t see the obvious name right away there are a few other things we can do.
- In the same search window, search for a path that contains either the expected program name, or the publisher name
- Search using “Publisher contains”
But the audit information stored for program files found on multiple computers is subject to some space saving optimizations that may cause unexpected results. For example, when you search for a path, you are looking at the “Sample Path” that is displayed globally just once for each program. Since programs can be installed at different paths on different computers, the Sample Path may not be what you expected – the majority of your computers may have the program installed elsewhere! If you know the Product is installed on a particular computer, the Show Audit window from the Computer Details window can sometimes be useful for exposing the correct program to include in the Product definition. But again, as a space saving optimization, K2 only stores a single path for each computer, even though there might be multiple versions of the program installed.
When all else fails, there is a way to reliably “find” the right program entry to include in your definition. Launch KeyConfigure on a computer that also has an installed copy of the product you are defining. Then drag the executable file from Explorer (on Windows, or Finder on Mac) directly into the KeyConfigure Programs window. This will select the program variant for that program – be sure the view settings for KeyConfigure’s Program window are set to display all Programs before dragging the executable into the Program window. From here, you can drag the selected program into the Products wizard or directly into a Products detail window.
Choosing the correct Variant Mask
The Add Product wizard will always suggest changing a mask of “all…” to a mask set to one decimal. In a Product Details window however, you can associate any Program Variant with the Product, regardless of how the Variant Mask is configured. Even though the user interface will let you drag an “all…” variant into a Product Details window – this will almost never give you a correct or useful definition! While distinguishing based on the first decimal is typical, you may sometimes need to use a Variant mask of two decimals.
For example, let’s look at the MATLAB product for Windows. The major Product release versions, 2011a, 2011b, and 2012a have corresponding executable versions 7.12.x, 7.13.x, and 7.14.x. A variant mask of one decimal would aggregate all of these 7.x versions together and be unable to correctly distinguish the Products (which are licensed and thus need to be managed distinctly) – so any time you see program versions that have little relation to the Product nomenclature, you should take a closer look. MATLAB is known to PRS so we have sorted out these subtleties for you – but if you have turned off PRS, or you run the New Product Wizard before allowing PRS to import standard product definitions, here is what you would see:
We have expanded the list in the upper left to show all minor versions within the Variant. Currently the arrow is pointing at 7.12, so we know that the path in the lower right is for version 7.12. The path contains R2011a, so we know which product this version belongs to. If we click to the left of each minor version, the arrow will move, and the Sample Path will update to reflect a sample for that specific version. If we look at 8.0 and 18.104.22.1681, we see that they are both minor versions within R2012b – so setting a Variant Mask of two decimals is correct.
One of the best ways to see if your Product Definition is correct is to test usage. Make a Site Policy for your custom defined Product. Run the program on client computers and use the Usage (PROD x comp) report to check that usage is being recorded. If you have older or newer Product versions also installed somewhere, you should create Product definitions for these as well. Then check that usage of the correct Product is being recorded by your Policy and that usage of the others is not being recorded.
Defining Products is very simple in concept – just associate the correct programs. In practice, it can take some time to decide which programs should in fact be Applications, and what the correct Variant Masks are. Hopefully this article helps, but if you get stuck, contact us and we can help.