Built-in Reports

KeyConfigure's internal reports allow administrators to seamlessly summarize usage and audit information, and view internal data in hundreds of ways.

The reports are supported by KeyServer's various databases, which are also accessible externally through the KeyServer ODBC driver, ksODBC, using any reporting tool. The internal reports have the advantage of being integrated into the User Interface.

Exporting Report Data

Reports can be exported using the “Save” or “Save As...” menu items from the File menu. Various formats including TEXT (tab delimited), HTML (viewable with a browser), and XML (for import into Excel) are available in a pull down menu from the save dialog. There is also a special export format, “KS Report Document” or KSR, that offers a compact, single file format for text and graphics that is readable by KeyConfigure (or KSRViewer, the light weight reader tool available from the Misc folder).

When a KSR is opened by KeyConfigure (or KSRViewer), the window that is presented will look almost identical to the original report window. Columns can be customized (just like a live reportl) and the data view can be sorted by clicking on the various column headers. When viewed with KeyConfigure connected to your KeyServer, line items within a KSR report can be double-clicked to connect to the underlying data object in KeyServer. Reports can also be printed from the file menu.

Report Categories

Programs displayed in reports

Generally speaking, all reports will ignore data from programs which are not part of any product. So, even if a program used to be in a Product in the past, and a Policy caused usage information to be recorded for the program, usage reports will not select launch and quit events if the program now has no product. Presumably if a program has been removed from a product, an administrator has decided that the program is not interesting, so reports should not show information on usage of the program. In addition, Usage related reports will only show programs which are Application components, since that is the only configuration which can generate new usage data. Audit reports also default to showing only Applications, but an option can be specified in the options pane to include all programs. One noteworthy exception to this rule is the Event Dump report, which is designed solely to show an exhaustive list of all events in KeyServer's usage database.

Computer Login types displayed in reports

Most reports will show data from all computers. However, Audit related reports will only show data for computers which are currently Dedicated or Leased. Computers marked as Excluded or Dormant will not appear in Audit reports.

Parameters and Interaction

In addition to using the Reports menu, specific reports can be invoked using the context menu attached to any appropriate selection in the user interface. This has the effect of passing the selected item as a parameter to refine the report's scope. The context menu for any selected item will list only those reports which can accept that item as a parameter.

You can also select multiple items. e.g., if you select five computers, then right-click and select a report, it will only contain data from those 5 computers. In this case, the Report Builder Window that comes up will show the 5 Computers in the Target Pane. There is a checkbox labeled “Aggregated”, which will be enabled for most reports. Checking this box will combine usage from all five computers into a single line item (named “*”). Leaving it unchecked will show five distinct entries for the five computers, as always.

Once a report has finished building its display, any item in the report can be manipulated in all the same ways that are familiar in other windows: double-clicking will open the details for the object, items can be dragged into appropriate targets, etc. You can even select a line in a report window and use the context menu to run a “sub-report” on just the selected item.

Most columns in a report will sort when you click in the column header. This is useful for quickly finding the most extreme cases of any particular attribute. For example in a report that lists launches and usage times, sort on the appropriate column to locate the program which is used most often, or the most number of hours. Many reports also have columns which are not visible by default. For example, all grouped reports have an optional column named “Count Details”. This column allows you to see how many details lines are contained under each group line. If you right-click in the column header area, you can “Customize Columns” to choose which columns to show or hide.

If a report has multiple views, you will see two little arrows next to the report name in the upper left of the report window. Clicking on the report name will bring up a pop-up menu that allows you to change views. In most reports this is used to “flip” the report. For example, if you are looking at a Usage (COMP x plcy) report (which groups by Computer), rather than run the Usage (PLCY x comp) report in order to see the report grouped the other way, simply click on the double arrow icon to switch the view.

As each report is selected from the Reports menu you will see a Report Builder Window where you can typically specify a date range on which to run the report.

If KeyServer data has been exported to an external database server then KeyConfigure's internal reports can be directed to the external data source instead of the KeyServer (assuming you have installed an appropriate odbc driver). This option is available from the Data Source pane of the Report Builder Window. For more information on ODBC as well as further report options, refer to the Report Builder Window documentation.

The following user interface items can be selected for use as parameters / restrictions on reports (via the context menu):

Naming Conventions

The report names are meant to be short, yet understandable and meaningful. We use the following standard abbreviations:

These abbreviations are used within parenthesis following the name of various reports. If there is only one term, the report will usually generate a flat list. For example, “Histogram (PRGM)” indicates a list of programs. If there are two terms in parenthesis, the first term (CAPS font) indicates the summary (header) records. Below the expansion icon for each summary record, the detail records (lower case font) are listed. For example, “Usage (COMP x plcy)” indicates a usage summary, where summary lines are computers, and detail lines are policies — “under each computer, list in detail the policies that were used”. In some cases, there might be a third level of detail, but this will not be referenced in the report name.

Audit reports

installed programs
RUN Audit (COMP x prgm)
RUN Audit (COMP x sn)
RUN Audit (PATH x prgm)
RUN Audit (PRGM x comp)
RUN Audit (PRGM x path)
RUN Audit (PRGM x sn)
RUN Audit (SN x comp)
RUN Audit (SN x prgm)

These reports show which programs are installed on various computers. When they are first completed, they are collapsed by default. This is because they may contain huge amounts of information. You can expand any particular group you want to look at by clicking on the expansion icon next to it, or you can right-click in the report window and Expand All. The most basic of these reports are Audit (COMP x prgm) and Audit (PRGM x comp), and they simply show which computers have which programs installed. These two reports are typical in that they only include Application programs. The Options pane of the Report Builder window does have a checkbox to “Include Utilities and Ignored Programs” Other reports group audit entries by path or serial number.

The Audit (COMP x prgm) report lists, under each computer, all the programs that are currently installed on that computer. This is similar to the information displayed when you select an individual computer and use its context menu item, “Show Installs”. However, the report only shows program variants while the “Show Installs” context menu shows variants which can be expanded to reveal individual distinct versions. This report has the advantage of consolidating the audit for all computers (or a selected Division) into a single window while suppressing unnecessary distinct version details.

The Audit (PRGM x comp) report lists, under each program, all the computers where that program is currently installed. This is similar to the information displayed for a single selected program using “Show Installs” from its context menu. Note: in both cases the “programs” we are talking about here are actually “program variants” — the same items that appear in the Programs window. To list instead the computers where a fully specified version is installed, use the “Version Installs” button in the program details window rather than the “Variant Installs” button (which does the same thing as “Show Installs”).

baseline / delta programs
RUN Audit Baseline (COMP x prgm)
RUN Audit Delta (COMP x prgm)

The Audit Baseline (COMP x prgm) report shows where programs were deployed as of the “baseline” date. By default, the baseline date for each computer is the time of first audit. This can be reset in the Computer Details window. All of the other audit reports show current program deployment based on all the most recent audit data available. You control how “current” to maintain the audit data in the “General Settings...” dialog from the Config Menu.

The Audit Delta (COMP x prgm) report is conceptually the difference between Audit (COMP x prgm) and Audit Baseline (COMP x prgm). It shows what programs have been installed, updated, or removed between the baseline audit date and the current audit date.

Both of these reports have the same columns as the Audit (COMP x prgm) and Audit (PRGM x comp) reports, but they also have additional columns.

programs which are members of a product
RUN Audit Products (COMP x prod)
RUN Audit Products (PROD x comp)

These reports show audit information, organized by product. Instead of simply showing where every program file is installed, they show where any program within a certain product is installed. This allows you to quickly see which computers might have certain products installed, and which products might be installed on a certain computer. Note that when a program is part of multiple products, these reports will attempt to determine which products are most likely installed, and will only display these products. For example, if all of the Applications within a Suite product are installed on a computer, that suite will be listed, while the individual point products will not be listed.

All programs, even those that are not installed
RUN Audit Summary (PRGM)

This report summarizes Audit information for all programs (even those not in products). It is similar to a fully collapsed Audit (PRGM x comp) report that has been run with the option to “Include Utilities and Ignored Programs”, but there is one important difference. The Audit report only shows programs which are currently part of an audit of some computer. Audit Summary (PRGM) shows ALL programs, regardless of whether they are currently part of an audit. One additional difference is that Audit Summary (PRGM) includes data from Dormant computers. Other audit reports exclude Dormant computers since they are less interesting and the audit data is older, but here for a summary they are included. This lets you identify programs which are no longer installed on any of your clients.

installed hotfixes
RUN Audit (COMP x fix)
RUN Audit (FIX x comp)

These reports show which hotfixes are installed on various computers. The format is very similar to Audit (COMP x prgm) and Audit (PRGM x comp).

products installed vs used
RUN Product Optimizations (COMP x prod)
RUN Product Optimizations (PROD x comp)

These reports are useful to identify cases where one product is installed, but a different, related product would be sufficient to satisfy usage demands. Within each Computer group of the Product Optimizations (COMP x prod) view, Products that are actually installed are displayed. Then expanding those products will show a list underneath of the product that could instead be installed and would still include all programs that were actually used from that product. This report does NOT show all installed products, it only shows cases where an installed product doesn't match the best product choice based on what programs are actually being used. For example, here is part of a Product Optimizations (PROD x comp) report.

Example of Product Optimizations (PROD x comp)

Here, the top level is installed products. In this case we're looking at one particular product, Microsoft Office 2013 Professional Plus Win. Underneath this are various other products that share some of the same components. This secondary list of products would be sufficient to satisfy usage demands on some of the computers that have the Pro Plus installed. The Count Details columns shows the number of items underneath each group. For the second level products, this count tells how many computers would be revealed by expanding the group entry for the potential alternative product. For example, looking at the bottom of the screenshot, there are 25 computers that despite having all 10 Pro Plus programs installed, have only actually used Microsoft Word. Using this report lets you choose appropriate entitlement counts for various related suites or point products, as opposed to simply buying an expensive suite for every computer on the assumption that it will be used.

Chart reports – Daily reports

RUN Daily (PLCY)
RUN Daily (PROD)
RUN Daily (PRGM)
RUN Daily Logins (DIV)

These reports let you see visually a usage pattern throughout the course of an “average” day. When the report is run on usage data spanning several days, all of the 1 PM data is averaged together for the 1 PM display, all the 2 PM data is averaged together for the 2 PM display, etc. Each “bar” of the histogram represents 10 minute of the day. The right side of the window lists each object (policy, product, program, division), and when you click on one, a graph is drawn on the left side of the window. The Daily Logins (DIV) report shows graphs of users logged into computers within the various divisions.

Clicking on the graph (left) portion of “Daily (PLCY)” will toggle between choosing the vertical axis to show the license total (if not infinite), and showing only up to the peak usage. This is useful if the license total is significantly higher than the peak usage, because it magnifies the vertical differences.

Chart reports – Histograms

RUN Histogram (PLCY)
RUN Histogram (PROD)
RUN Histogram (PRGM)
RUN Histogram Logins (COMP)
RUN Histogram Logins (DIV)
RUN Histogram Logins (USER)

These reports let you see visually a usage pattern over the specified time range. The right side of the window lists each object (policy, product, program, division), and when you click on one, a graph is drawn on the left side of the window. The Histogram Logins (DIV) report shows graphs of users logged into computers within the various divisions. Histogram Logins (COMP) and Histogram Logins (USER) are similar but group by Computer or User. Usually these are less interesting since they may simply show alternation between 0 and 1 logins.

Clicking on the histogram (left) portion of “Histogram (PLCY)” will toggle between choosing the vertical axis to show the license total (if not infinite), and showing only up to the peak usage. This is useful if the license total is significantly higher than the peak usage, because it magnifies the vertical differences.

The Histogram reports have many columns which are hidden by default. These are the same columns which are shown in the Summarize reports.

Chart reports – Histogram Lease

RUN Histogram Lease (PLCY)

This report is much like Histogram (PLCY), but instead of charting policy usage over time, it charts allocations of the policy over time. So for a Lease or Node policy, this report gives the graph of the value that is restricted by the license limit. So while Histogram (PLCY) will give you a better sense of actual usage patterns, Histogram Lease (PLCY) will show you how close to the license limit you actually got over time.

Chart reports – Weekly reports

RUN Weekly (PLCY)
RUN Weekly (PROD)
RUN Weekly (PRGM)
RUN Weekly Logins (DIV)

These reports let you see visually a usage pattern throughout the course of an “average” week. When the report is run on usage data spanning several weeks, all of the Monday data is averaged together for the Monday display, all the Tuesday data is averaged together for the Tuesday display, etc. Each “bar” of the histogram represents 1 hour of a day. The right side of the window lists each object (policy, product, program, division), and when you click on one, a graph is drawn on the left side of the window. The Weekly Logins (DIV) report shows graphs of users logged into computers within the various divisions.

Clicking on the graph (left) portion of “Weekly (PLCY)” will toggle between choosing the vertical axis to show the license total (if not infinite), and showing only up to the peak usage. This is useful if the license total is significantly higher than the peak usage, because it magnifies the vertical differences.

Configuration reports

RUN Config Sections
RUN Config (PLCY x pool)
RUN Config (PLCY x prod)
RUN Config (PRGM x prod)
RUN Config (PROD x plcy)
RUN Config (PROD x prch)
RUN Config (PROD x prgm)

The Configuration reports are very simple. Each one shows the relationship between different objects in KeyConfigure. Config Sections shows each Division, Policy, and Purchase associated with each Section. Config (PLCY x pool) shows the pools within each policy (most policy types only have a single pool). Config (PLCY x prod) shows what products are managed by each policy. Config (PROD x plcy) shows what policies apply to each product. Config (PROD x prch) shows all the purchases for each product. Config (PROD x prgm) shows the programs which make up each product. Config (PRGM x prod) shows the products which each program is part of. The columns should be self explanatory.

Denial reports

RUN Denials (COMP x prgm)
RUN Denials (DIV x prgm)
RUN Denials (PRGM x comp)
RUN Denials (PRGM x div)
RUN Denials (PRGM x user)
RUN Denials (USER x prgm)

These reports simply show which programs were denied (a user tried to run the program, but was denied because they need a license and could not get one), and how many times they were denied. These reports always involve programs, since that is what gets denied.

Login reports (split by day/hour/15 minutes)

RUN Login Average Counts (DIV)
RUN Login Average Peaks (DIV)
RUN Login Average Users (DIV)
RUN Login Counts (DIV)
RUN Login Peaks (DIV)
RUN Login Users (DIV)

These reports summarize Login information within each Division, split out by day, hour, or 15 minute segments (use the “Options” pane in Report Builder to specify granularity). They show maximum concurrent logins (Peak) and/or unique users (Users). The first three reports average these counts across multiple weeks - showing for example “what is the average peak number of logins between 9:00 AM and 10:00 AM on Mondays”. The remaining reports do not average, so will show for example peak usage on each specific day in the time range you run the report on.

These reports are formatted in two different ways. All of them group first by Division. The two “Counts” reports show specific days (or hours or 15 minute segments) on the detail lines, and each detail row shows both the Peak logins and Unique Users. The “Peaks” and “Users” reports use columns to arrange data by days of the week - so these reports only show Peak logins (in the seven day columns) or Users. Again, detail rows are for time segments, but there are 7 times fewer detail rows than in the “Counts” reports, since these samples have been “wrapped” into day columns.

The “Counts” reports when saved as text or XML should provide data that is easy to manipulate with Excel. The “Peaks” and “Users” are designed to be easier to read on screen, and might be less appropriate to provide data to Excel.

Almost all of these reports round the specified time range out to complete weeks. This is because the Average reports are averaging across weeks, and the Peaks and Users reports present a complete week as multiple columns, one per day. The one exception is the Login Counts (DIV) report, which only rounds to complete days, since it is not doing anything related to weeks.

For the “Peaks” and “Users” reports, when you select a granularity of “Hour” or “15 minutes” you can also limit output to certain hours within each day. Specify “from” and “through” hours from 0 to 23.

Login reports

RUN Logins (COMP x user)
RUN Logins (DIV x comp)
RUN Logins (DIV x user)
RUN Logins (USER x comp)
RUN Logins (USER x div)

These reports summarize Login information. They show who logged in from where, and for how long.

Logins OS Percent reports

RUN Logins OS Percent (COMP x user)
RUN Logins OS Percent (DIV x comp)
RUN Logins OS Percent (DIV x user)
RUN Logins OS Percent (USER x comp)
RUN Logins OS Percent (USER x div)

These reports are identical to the standard Logins reports except that they have additional columns describing what percent of logins occurred as different platforms. This is useful for understanding how “Dual Boot” computers are being used. Note that Virtual Computers have their own computer records in KeyConfigure, and there is no easy way to correlate which Virtual Computers are being run on which Physical computers. The standard columns show percents by duration. For example if “Total Time” is 4:00 and “% Mac” is 25%, then the logins totalled 4 hours, and 1 hour of this was on Mac. There are optional columns which will show percents of counts. For example, if “Total Count” is 10 and “# % Mac” is 60%, then there were 10 total logins and 6 logins on Mac.

Miscellaneous reports

Duplicate reports

RUN Duplicate MACs (COMP)
RUN Duplicate Names (COMP)
RUN Duplicate SNs (COMP)

These reports are similar to the Hardware report, but only show computer records which may be Duplicates. Duplicate computer entries occur when a single client computer is unreliable in recognizing hardware properties such as MAC address. KeyAccess on that computer may start out using one computer ID, but then be forced to switch IDs when the hardware properties appear to have changed.

Duplicate MACs (COMP) looks for multiple computers where the MAC address is identical. Duplicate Names (COMP) looks for multiple computers where the Name is identical. Duplicate SNs (COMP) looks for multiple computers where the Name is identical. At sites where computer names are guaranteed to be unique (based on central deployment or domains), the name based report should be good at identifying duplicate records. But for a site where computer names are not unique, the results are not so meaningful. If the reports give the message “No data to report on”, it means that your data does not contain any duplicate computer entries.

If the data in a column is displayed in bold, then the computer ID for the computer is based on that piece of data. For example, if the MAC column for a particular computer is in bold, then the computer ID is the letter “N” plus the MAC address. If the value is also dimmed (medium grey instead of black), then the computer record doesn't actually have a value recorded for this property, but it is displayed in the report since it can be inferred from the computer ID.

The “Dup?” column lets you sort apart the computers according to what type of entry this report has guessed that they are. If this column is empty for a particular computer, it means that this computer record is almost certainly still in use, and should not be deleted. In Duplicate Names (COMP), if the column contains a question mark (?), then this row shares the computer name with another entry, but has a distinct MAC address. This means that the computer could be a duplicate entry which should be deleted, or it could be a unique entry which simply has the same computer name. For these rows, you should sort by name, and compare this row to other rows with the same name, to see if other hardware properties match or are distinct. If the column contains a red “x”, then this row is almost certainly a duplicate and should be deleted. Not only does it share the computer name with another entry, it also has the same MAC address (or the other entry has a MAC address and this entry has no known MAC address).

These reports are intended to be used in order to identify and delete duplicate computer entries. After running the report, it is recommended that you create a new computer division, to temporarily move duplicates into. Then sort the report by the “Dup?” column. Scroll to the bottom and select all the computers with an “x” in that column, then drag them to the new division. Now you can filter the main computers window to show only those computers in the new division, select them all, and cut them (delete them). Alternatively you can set them to either Dormant or Excluded, so they will no longer take up a KeyServer seat.

Event Dump

RUN Event Dump

Event Dump is the most detailed report on usage information. As such, it is probably not generally that useful, but is extremely valuable in certain situations. It shows, in chronological order, one line for every single event which KeyServer records. All events relate to Server startup/shutdown, Computer audit, client activity, Program launch/quit, and Policy usage.

Caution: on a KeyServer supporting thousands of clients with heavy usage data going back several months, the Event dump might require several gigabytes of memory space to hold perhaps many millions of event records. In order to avoid virtual memory thrashing, you should always run the Event Dump report on a limited data set. Restrict to a specific time period of interest, and/or select a specific Computer, Program, or Policy. Use its context menu to run the report — this will download events concerning only the selected item.

This report can be given any of the five types of parameters (computer/product/program/policy/user). Regardless of parameter type, server events are always shown.

Under a few conditions, lines will be highlighted in red. These are events where something is wrong. These are the specific conditions:


RUN Hardware

This report is similar to the Computers Window, but shows many more attributes of each computer. All of the information displayed can be seen in each individual Computer Details Window, but this report allows all of the information to be seen at once, and will sort the computers by any of the attributes which are displayed. The Computers Window can in fact be customized to show additional values as well, but still, the Hardware report may be a convenient way to quickly see a long list of values for each computer.

If the data in a column is displayed in bold, then the computer ID for the computer is based on that piece of data. For example, if the MAC column for a particular computer is in bold, then the computer ID is the letter “N” plus the MAC address. Most likely, almost all of the computers will be using the same attribute for the computer ID. If the value is also dimmed (medium grey instead of black), then the computer record doesn't actually have a value recorded for this property, but it is displayed in the report since it can be inferred from the computer ID.

Lease Simulator (PLCY)

RUN Lease Simulator (PLCY)

This report helps you determine how many copies of a license you would need if you changed the policy to a lease policy. When it runs, it looks at historical policy usage, and simulates what would have happened if the policy had already been a lease policy, and there were allocations of a lease, using different lease durations. You can run this report on any date range, but the longer the range you use, the more meaningful it will be. The format of the report is very simple: there are columns for various lease durations, so for each policy, you can see what the peak allocation would have been assuming those different durations.

Missing Clients

RUN Missing Clients

The Missing Clients report compares computer names known by KeyServer to computer names known to an LDAP server. This is useful to determine if there are computers at your site which do not have KeyAccess installed, or maybe have KeyAccess pointed to a bad KeyServer address, or are behind a firewall that prevents them to reach KeyServer.

In order to run this report you must enter LDAP configuration values in the Options pane of the report builder. Depending on the operating environment in which the report is run, some or all of the configuration fields can be left blank, and will be determined automatically. For example, running this report in KeyConfigure on Windows where the computer and user account are part of a domain, the LDAP Host value will be the AD server, the LDAP credentials (login and password) will be the logged in user, and the Base DN will be retrieved from Active Directory. In this environment, all of the configuration fields can be left blank. Likewise, if KeyReporter (stand-alone or as part of KeyServer) is running in a domain account on a computer that is a member of the domain, no extra configuration is required.

Node Locked reports

RUN Node Locked (COMP x plcy)
RUN Node Locked (PLCY x comp)

These reports show information related to Node policies only. They show where node-locks have been allocated, where programs which are managed by node-lock policies are installed, and where these two conditions do not exactly correspond.

There are three basic cases which are represented in these reports.

  1. A computer has a node-lock allocated to it for a policy. It also has at least one program which is managed by the policy installed, and furthermore, that program has been used recently. This is the “normal” case, where node-locks have been allocated correctly.
  2. A computer has a node-lock allocated to it for a policy, but does not have any programs installed which are in a product managed by the policy. This may happen if an administrator allocated node-locks manually, before installing software on the computer, or if a computer used a program once, but has since uninstalled the program. In this case, the node-lock is not necessary. In the same category are cases where the program is installed but has not been used in over 90 days. These are likewise candidates for removing the lock.
  3. A computer has a program installed which is in a product managed by a node-lock policy, but the policy has not been allocated to the computer. This may happen if the program has been installed, but not yet used (or if a standard image installs the same program on all computers, regardless of whether it is needed on each computer). In these cases either the policy should be locked or the program should be uninstalled.

Both reports show exactly the same information, but organize it in different ways. Since a single policy can manage multiple products containing multiple programs, there is a third level of detail showing the program or programs that are actually installed that correspond to each particular policy/computer pair. The mid-level line (computer or policy) shows the status for that computer/policy pair. The top-level line shows an overall status for that computer or policy, which summarizes and generalizes the status of the mid-level lines below that top-level line. Note that these reports get “Last Used” information from audit and Node Locked records — they do not directly access usage data. The only time Usage events would differ significantly from the data used here is if a policy has been recently created.

Top-level Status strings:

Mid-level Status strings:

Path Browser

RUN Path Browser

The Path Browser report shows Programs organized in a path hierarchy based on the Sample Path where each Program was first discovered. While this sample path may not in fact be the common path that results from a standard install, it is often the standard path, and so the report mimics what you would see “on disk” if a single computer had all known programs installed on it.

Product Catalog reports

RUN Product Catalog (PROD x sect)
RUN Product Catalog (SECT x prod)

The Product Catalog reports list the products that are available for use on computers in each Section. The idea is that Products that have a Policy are the products available in your complete product catalog. However this list of Products might be different for different Sections.

Product Suggestions (PROD)

RUN Product Suggestions (PROD)

The Product Suggestions report looks for Manually defined Products that might correspond to an Automatic Product defining the same thing. A Manually defined Product is one that a KeyServer Administrator at your site has created using the New Product wizard. An Automatic Product is one that was defined by Sassafras and downloaded by the Product Recognition Service.

If an application program appears in both a Manual product definition and an Automatic product definition, the report will suggest the Automatic Product as a possible replacement. But for suite products, noticing a single application in common is a long way from claiming the definitions actually correspond, so you must examine any suggestion carefully before accepting it as a replacement! When an Automatic product is in fact a good match to your Manual product, often it is more accurate in specifying program variants or more complete in listing Utilities. Also, if Sassafras discovers a misconfiguration of the Automatic Product definition at some future date, PRS will automatically update the definition.

The output of the Suggestions report shows Manually defined Products on group lines, and within each group, one or more Automatic Product suggestions are listed. If a Manually defined product has been carefully defined and is very close to matching an Automatic Sassafras definition, then you might see just a single Automatic product listed underneath. If the Manually defined product is a suite which Sassafras has not yet defined, but Sassafras has defined the related point products, you will see all those point products listed.

When your KeyServer Data Folder has a long history of upgrades going back to version 6.2 or older, the upgrade process may have created a catch-all product named “(6.x ->logged Product)” consisting of all the logged programs from the legacy KeyServer. The Suggestion report may list many Automatic products as a candidate replacements just because each one shares at least one program file. But a quick examination reveals that none of these suggestions are a good match! Very often, the “(6.x ->logged Product)” serves no current purpose and can be deleted entirely or replaced by a more carefully constructed Manual product that focuses on just a few programs that are not already logged due to other Policies.

Once you have carefully examined the Product Details window for a Manually defined product, as well as the suggested Automatic products, you might decide that you want to use one (or more) Automatic products instead of your Manually defined product. The Replace Product References wizard makes such a switch easy, updating all references in Purchase and Policy records as necessary. From the Suggestions report select a Manual product. With the Automatic product suggestions exposed underneath, you can also select a replacement. Then right click to run the context menu item, “Replace Product References”. The wizard will open with your selected items filled in!

Great care should be taken when using the Replace Product References wizard since the changes are not easily reversible!

Automatic Products never include keyed variants as part of the product definition, so if your Manual Product has a keyed Application component, you must manually add this component to the corresponding Automatic Product after the Replace Product References wizard completes. Note: while the PRS will occasionally update an Automatic Product if necessary, such an update will never add or remove any keyed variants from the definition.

It is common to see a Manual product defined to include not only the most recent program variant but also all older variants in order to facilitate “backward coverage” whenever the product is managed by a Policy (e.g., so that older program variants are allowed to continue being used until upgraded). When adopting an Automatic product in place of a Manual product a different method for handling “backward coverage” is required. In Policy records (but not Purchase records), the replace wizard can replace the selected Manual product with multiple Automatic products. In fact the Suggestions report supports selection of multiple Automatic products to replace your single Manual product selection for just this reason. The most recent Automatic product will be used as the “primary” replacement in any affected Policy and also in any affected Purchase record, so the reconciliation balance (or imbalance!) between purchases and policies is preserved by the replacement.

Reconcile (PROD)

RUN Reconcile (PROD)

The Reconcile computes the Entitled count for each Product/Metric, from all relevant Purchase records. It compares this to the Managed count which is computed from all relevant Policy records. The numbers presented in this report match the output of the Reconcile Window. The Reconcile Window is more interactive, but the Reconcile report can be saved as a KSR.

Session Dump

RUN Session Dump

Session Dump lists a single line for every KeyAccess session with KeyServer. Columns display the Computer, User, time of Logon, time of Logoff, Duration, and Address.


RUN Shadow

This report shows a list of shadows that served at some point in the specified time period.

Suite reports

RUN Suite (PLCY x prgm)

This report shows you a summary of policy usage, including program usage. The group headers are policies, and show usage summaries for each policy over the time period. The details are programs, and show usage summaries for the program, in the cases where it was enabled by the particular policy.

If the same program is managed by multiple policies, it may appear on multiple lines in the report, under different policies.

It is important to note that the header lines do not necessarily show a sum of the detail lines. They show a usage summary for the policy. So if it is a suite policy (one which manages multiple products), the policy usage total may be less than the sum of the program usage totals, since computers may have used multiple programs at the same time. Likewise if a policy manages a single product but the product is a suite product with multiple programs, the Suite (PLCY x prgm) report may show multiple detail lines which don't add up to the group line. This is different from most reports, where instead each group line is a summary of the details below it.

Upgrade Discoveries (PRGM)

RUN Upgrade Discoveries (PRGM)

This report is designed to help identify Program Variants for which you are likely to want to define a Product. It shows Program Variants that are not currently an Application in any Product, but for which an earlier version in the same program family IS an Application in a product. It is likely that these newer versions should in fact be configured as an application in some product. Note that there is a widget in KeyReporter (“Upgraded Programs”) that shows the same programs that this report shows. It may be more efficient to include this widget in your dashboard and watch for newly discovered programs, than to manually run this report from time to time.

Upgrade Discoveries (PROD)

RUN Upgrade Discoveries (PROD)

This report is designed to help identify Products for which you are likely to want to define a Policy. It shows Products that currently have no Policy, but for which an earlier version of the same product DOES have a policy. It is likely that these newer versions should in fact be configured with a Policy. Note that there is a widget in KeyReporter (“Upgraded Products”) that shows the same products that this report shows. It may be more efficient to include this widget in your dashboard and watch for newly discovered products, than to manually run this report from time to time.

Purchase reports

Compliance (PROD)

RUN Compliance (PROD)

The Compliance report looks at Product configuration, Purchase records, Policies, Audit data, and Usage data. It compares purchase data to all of the other data in order to determine compliance. The columns are as follows:

RUN Purchases (PROD x prch)
RUN Purchases (PUBL x prch)

Purchases (PROD x prch) is very similar to Config (PROD x prch). However, the Config report is merely listing purchases for a product, while the Purchases report is more suited for reporting on purchasing. It has some additional optional columns, and it can accept a time range will will limit the report to just the purchases made during that time range. Purchases (PUBL x prch) groups by publisher instead of by individual product.

Summarize reports

RUN Summarize (DIV x plcy)
RUN Summarize (DIV x prod)
RUN Summarize (DIV x prgm)
RUN Summarize (PLCY x div)
RUN Summarize (PROD x div)
RUN Summarize (PRGM x div)
RUN Summarize (PLCY)
RUN Summarize (PROD)
RUN Summarize (PRGM)
RUN Summarize Logins (DIV)
RUN Summarize Logins (USER)

These reports give an overall summary of configuration and usage statistics. Unlike the Usage reports, they do not show information about where policies and programs were used, but they do give overall summaries like peak Concurrent Usage.

Usage reports

(PLCY x comp)

(COMP x plcy)
(PROD x comp)

(COMP x prod)
(PRGM x comp)

(COMP x prgm)
(FLDR x comp)

(COMP x fldr)
(PLCY x div)

(DIV x plcy)
(PROD x div)

(DIV x prod)
(PRGM x div)

(DIV x prgm)
(FLDR x div)

(DIV x fldr)
(PLCY x pool)

(POOL x plcy)
(PROD x pool)

(POOL x prod)
(PRGM x pool)

(POOL x prgm)
(PLCY x user)

(USER x plcy)
(PROD x user)

(USER x prod)
(PRGM x user)

(USER x prgm)
(FLDR x user)

(USER x fldr)

These reports all summarize usage information for policies, products, or programs (actually “program variants”). Each report pair presents the same information but with the summary and detail fields interchanged.

The division reports (DIV or div) aggregate together information from all the computers within each division.

The pool reports allude to the “pools” which can be set up in a custom policy in order to enforce group membership requirements that restrict access to each pool. Pool reports show which group requirement allowed the usage of a policy, product, or program, either through a pool in a custom policy, or through a group scope for a policy. Any usage which did not require group membership shows up as “universal”. If you have not set up groups, group scopes on policies, or custom policies with multiple pools, these “pool” reports will not be very interesting since ALL usage would be detailed with a single line: “universal”.