This document is written specifically for upgrading directly from 6.x to 7.4. To see the (much more simple) instructions for upgrading from 7.0 / 7.1 / 7.2 / 7.3 to 7.4, refer to the Major Upgrades from 7.x documentation. Conversely, there are MANY changes to both the management interface and functionality when upgrading to 7.4 from KeyServer 5.x. Be sure to read TN5, which is devoted to this subject, before upgrading.
Any upgrade of the KeyServer components should be done with special care since a mistake could affect access to licensed software on all of its clients. The server installer will take care of preserving your various configurations, but you should still understand the process of upgrading. Since the KeyServer process must be shutdown during the upgrade, it will be unable to respond to license requests or collect audit and usage data for a period of minutes or even hours if a large data file needs repair. In a typical configuration, clients will tolerate the outage without user disruption because the default setting for unkeyed managed programs is to allow usage when KeyServer is not available. Offline usage data will later be uploaded when the KeyServer process is re-started and clients re-connect.
Before proceeding with an upgrade of the KeyServer:
*Even though KeyServer version 7.4 will manage keyed programs on clients using KeyAccess versions back to 5.x, management of unkeyed programs on old clients will change as soon as the KeyServer is upgraded. In particular, KeyAccess versions prior to 22.214.171.124 will no longer control unkeyed programs launches and versions prior to 126.96.36.199 will not log unkeyed usage.
File formats and database names have been changed with each major upgrade of KeyServer. Starting with version 6.1, translation of data formats is handled by the utility program KSdbConsist which is included as part of the server installer. This utility runs automatically as part of the install process whenever a KeyServer Data Folder is found in the standard install location. It is also installed alongside KeyServer and may be used at any time to check data integrity of KeyServer data files.
When run within the server installer, KSdbConsist will always transform 6.x formatted data files from an existing install into 7.4 formatted files (moving the originals aside as described below). When used as a standalone utility, KSdbConsist can be pointed to a folder at any location and it will inspect and repair any enclosed KeyServer data files. If any file needs repair, it will first be moved into the Backup Folder inside the data folder.
If your KeyServer is managing many thousands of client computers, you may want to do a "dry run" of the upgrade in order to do some off-line testing. In this case, follow the procedure described in "Moving KeyServer to a new Host". After testing an off-line KeyServer upgrade, a possible upgrade strategy would be to swap it with the old online KeyServer - but any new usage records collected since the offline upgrade was created would be lost (not to mention configuration changes, if any). Generally, the time and disk space requirements are small enough that it will be simplest just to re-run the upgrade procedure on the active KeyServer.
The paragraphs below describe several important issues to be aware of before performing the upgrade steps. The basic steps are the same when upgrading from either version 6.x or 5.x but if you are upgrading from version 5.x, first read TN5, which is devoted to this subject, before upgrading.
The version 7.4 KeyServer requires a license certificate, server.lic, that supports version 7.4.
Before running the installer to upgrade a 6.x KeyServer installation, you must have a license certificate ("server.lic") that supports version 7.4 in place within the old KeyServer Data Folder. Without a valid 7.4 certificate, the installer will not perform an upgrade. The 7.4 certificate will support the older KeyServer versions – when you obtain your 7.4 server.lic file via e-mail from Sassasfras Software, put it in place even if you don't plan to upgrade immediately. Note: you will have to remove the old server.lic (or just rename it, "server.old") before putting the new 7.4 server.lic file in its place.
The version 7.4 KeyServer requires version 7.4 of the Admin component, KeyConfigure.
An older KeyConfigure (e.g. version 6.2) will not connect to an upgraded 7.4 KeyServer. Before upgrading the KeyServer to 7.4, it will be most convenient to first install KeyConfigure 7.4 on the computer you use as an administrative console. The Admin installer will move aside any old KeyConfigure version that it finds in its standard install location. For example, if you have KeyConfigure 6.2 installed, the “Admin” folder will be moved to “6.2 Admin”. Since multiple KeyConfigure versions can happily co-exist on your admin machine, you will then be able to choose the appropriate KeyConfigure in order to manage both your old and new KeyServer versions if necessary during the upgrade transition.
The previous KeyServer folder (old version) is set aside.
When upgrading from version 6.2 or earlier, the "K2Server" installer will set aside the existing server folder and change its name appropriately (e.g. "6.2 Server BACKUP"). The moved aside data files will be used as the basis for creating reformatted data files in the new KeyServer Data Folder. Note: in order to save space, the Log Files sub-folder from the original data folder is moved into the new KeyServer Data Folder (from "6.2 Server BACKUP") rather than being copied. Also, the Export Files folder (if present) is not carried forward. If it is necessary to revert to the prior KeyServer install for any reason, the moved aside backup folder can be quickly put back in place - it is unchanged except for the moved Log Files sub-folder. If it becomes necessary to revert to the previous version, the steps are outlined in this technote – but new usage and configuration data will be lost.
The Linux and Solaris installers are not so automated ! - you will have to create your own backup of the existing installation in order to facilitate an instant reversion in case of trouble. However, these installers do move any data file into the folder "KeyServer Data Folder/Backup" whenever a new format file is created (so reversion is possible, without a backup, even though not so simple).
The version 7.4 KeyServer requires new formats for several of its data files.
The installer will run KSdbConsist, which will perform data conversion as necessary.
If your previous KeyServer is configured to export its databases to a remote database server, you will want to update the table structure in the external database once you have completed the KeyServer upgrade - though this can be done when you have time - no data will be lost if it is not done immediately. See the Tables document for information on new fields and tables, as well as SQL queries to update the format as necessary.
The time required for KSdbConsist to complete its checks, repairs, and data reformatting can vary from minutes to hours depending on the size of the existing data files, as well as whether they need repairs. The Usage Log and the Software Audit Database are usually the largest files by far, and therefore the most time consuming to process. The time required can be reduced somewhat by accepting the KSdbConsist default setting, "don't import the Software Audit Database". The Audit Database will then be rebuilt automatically over the next few weeks based on KeyServer's normal "Reschedule audit every n weeks" setting. Of course historical "base audit" information will be lost by accepting this default - the advantage will be a pruning of orphaned audit records left over from computers that you may have deleted long ago.
If you are running a very old KeyServer, you may be tempted to start over with a "clean" install so that you can make fresh license management decisions and get rid of old clutter. Besides the obvious consequence of losing direct access to old usage data, this strategy may also orphan old programs that were previously controlled using the optional "keying" feature.
The crucial data that is required to bring a "keyed" program copy to life is contained in the "License Data" file from the KeyServer that was in use when the program was originally keyed. While it is technically possible to import "keys" from these old format files using KeyConfigure 7.4, the imported license configuration data may not be complete. It is much better to let the upgrade procedures described below import and reformat the old license configuration data (assuming the data remains where it was originally installed so the installer will find it). You can then easily reconfigure and delete clutter after the upgrade.
There are some interface and feature changes in 7.x which you should be aware of. These changes are described on the "Important Changes from 6.x to 7.x" page, which KeyServer 6.2 administrators should read.
Before upgrading, there are a couple of things you can do which will make the process smoother.
1. Look at Program rules.
Any Program rules which set an action but no folder will turn into a simple filter. If you want them to remain a rule (to identify possible candidates to make products), you should create a folder for that rule, and change the rule to set the folder.
2. Run the Control (PROG x lic) report, and save it as a ksr.
After upgrading, you might want to refer back to the essential configuration from your older KeyServer, without actually reinstalling the older KeyServer version.
Here are the steps for upgrading to version 7.4 from version 6.2 or earlier. Note: unlike for a minor upgrade, canceling KSdbConsist before it is finished will abort the entire upgrade process.
1. Replace the License Certificate file, "server.lic", located inside the KeyServer Data Folder with a new certificate that supports version 7.4.
The new server.lic file is sent via e-mail when you purchase the 7.4 upgrade, or is sent automatically under your Upgrade Subscription Program entitlement. The text line "license.range=5.0-7.4" in this file means that it will enable any KeyServer version from 5.0 through 7.4 - you can immediately use it in place of your old server.lic file, even if you are not ready to upgrade yet.
The standard install location on Windows is either C:\Program Files\Sassafras K2\Server\ or C:\Program Files (x86)\Sassafras K2\Server\ depending on your OS.
The standard install location on Macintosh is /Library/KeyServer/
2. Run the K2Server component installer - this will use the KSdbConsist utility to check data files.
If KSdbConsist is cancelled before completing, the original KeyServer folder (renamed with the suffix "BACKUP" by the installer) will be moved back to its original location and the upgrade will abort.
3. Restart the KeyServer service.
In order to activate the new software version, restart the KeyServer process - use the services control panel or terminal utility or just re-boot the host computer.
4. Use KeyConfigure version 7.4 to connect and verify settings.
Use your old KeyServer password - it has been preserved in the upgrade to 7.4. After your password is accepted, you will see a dialog titled “Configuring KeyServer 7.4”. The primary task being performed is importing standard product definitions. This should not take long - probably just a minute or two (although it will take longer if your computer cannot reach sassafras.com to download the latest definitions and instead falls back to the definitions included with the KeyConfigure installer).
The following steps are not strictly necessary, but they will help you gain a much better understanding of how your data looks different in the new KeyConfigure 7 interface (even though almost all functionality and configuration has been preserved).
1. Enable KeyReporter on the KeyServer computer.
In earlier versions of K2, KeyReporter was a separate installer, and could be run either on the same computer as KeyServer or on a different computer. Starting in version 7.2, KeyReporter is part of the KeyServer install and (optionally) gets sublaunched by KeyServer. This allows tighter integration of KeyReporter with KeyServer and KeyConfigure.
If you have an installation of KeyReporter version 6, there are two pieces of data/configuration which you may wish to migrate to your 7.4 installation. After installing 7.4, but before enabling KeyReporter, you can copy:
You can migrate these files over whether KeyReporter is installed on the same computer as KeyServer or a different computer. To locate the old KeyReporter Data Folder, refer to the 7.1 file locations document. For the 7.4 locations of both KeyServer and KeyReporter Data Folders, refer to the 7.4 file locations document.
Finally, if you are running KeyReporter version 6 on the same computer as KeyServer, you should remove/disable it before trying to enable the new KeyReporter
On Windows, uninstall "Sassafras K2 Reporter" in Add/Remove Programs.
On Mac, do:
sudo launchctl unload -w /Library/LaunchDaemons/com.sassafras.KeyReporter.plist
When you login with KeyConfigure 7.4 (using an account with sufficient privileges), you will see a wizard like the one shown below:
This wizard allows you to configure the ports that KeyReporter will run on, as well as setting passwords to enable Guest access and scheduled reports. For more details, see the KeyReporter Setup documentation.
2. Enable PRS, the new Product Recognition Service.
Shortly after logging in for the first time, you will see a wizard like the one shown below:
This special first screen is presented when upgrading from an earlier version of KeyServer. A similar wizard will automatically appear any time in the future that PRS needs to add or change Sassafras-defined products which have an affect on Policies. If you click "Update Now", all the necessary changes will be applied and then you will have the option to save a report listing all the Policies affected by the changes. If instead you select "Step Through Details", you will see a preview of the changes that need to be made before applying them. For more detail on the other screens of this wizard, see the Product Update Wizard documentation. If you Cancel, you will not be able to turn on the Product Recognition Service.
Once you update products in this first run Wizard, you will see this final screen where by default you will turn on PRS:
When PRS is turned on, it will immediately send some data to the PRS server in order to receive any new product definitions that are relevant to your site. This initial communication, and download of new definitions, should complete within a few minutes. It is very likely that importing these Product definitions will have an affect on a Policy, so you will probably see the wizard a second time as you start to go through the remaining steps documented here. After importing these new definitions, you will be fully up to date with PRS. PRS will be configured to run nightly, but now you should only see a Product Update Wizard when Sassafras creates a new Product definition for something at your site, or when a new Product is installed for the first time at your site.
3. Look at Admin Access.
From the Windows menu, select Admin Access. This window corresponds to the Accounts dialog in 6.x. It is divided into three parts, separated by horizontal lines. At the top are Roles, which are new in 7. Next are Groups, which are new in 7.3. At the bottom are Accounts, which have been converted from your old data.
The default Accounts from 6.x other than Administrator have been deleted and recreated in order to ensure proper privileges. These accounts are “External Report Account”, “KeyReporter Guest”, and “KeyReporter Schedule”. If you have customized passwords and privileges for these accounts in 6.x, you will have to do that configuration again in 7.4.
All other accounts have been converted in a way that maintains the existing password and privileges. Privileges in 7.4 are no longer specified directly in the Account, instead they are defined in Roles. Then each Account can have various Roles. Generally during Conversion, each Account gets a new Role definition in 7.4 in order to get the correct privileges. If two accounts in 6.x have the same privileges, they may both have just a single Role in 7.4 - but this is not guaranteed during conversion since some Accounts may appear the same but differ slightly in a way that causes KSdbConsist to create two Roles. A single Role shared by more than one account will have a generic name such as “(6.x -> #1 Role)”. A role that has been created for a single Account will contain the Account name, e.g. “(6.x -> fred Role)”.
If you double-click any Role, you will see a list of Privileges that looks familiar, much like those in 6.x. There are some new Privileges in 7.4. The initial state of these new privileges is mostly turned off, since there is no way to guess whether they should be allowed for any particular Account. Policy Privileges come from License Privileges in 6.x since these are so closely correlated. Product Privileges also come from License Privileges. Although Products are new, they are functionally a part of what used to be entirely encompassed in Licenses.
You will also notice some additional Roles, which do not correspond to any 6.x Account. One of these is the “Proxy Role”, which is used by KeyReporter Schedule to allow different logins to create scheduled reports. Another is the “Report-only Role”, which is used for all three of the default Accounts, since they are all used for reporting. Additionally, if you had any report only accounts in 6.x which were limited to a Division, KSdbConsist will create an “All divs Role”, which will be given to any accounts which are not Division limited. This Role has Access Permissions for all Divisions. For more about Roles, see the Admin Access documentation.
4. Understand how products have been created.
In 6.x, programs were associated directly with Licenses. A “Suite License” was effectively a product definition as well as a licensing policy. In 7.4 this is explicit - there is a Product definition which aggregates related programs into the product which is purchased and should therefore be managed, and there is a Policy which defines the Metric for managing that product.
So, during conversion of simple data from 6.x, a single 6.x License becomes a 7.4 Product as well as a 7.4 Policy, both with names based on the 6.x License. There are slightly more complex configurations that KSdbConsist will recognize however. If two 6.x licenses control the same set of programs, KSdbConsist will make a single Product which is controlled by both 7.4 Policies. If the two Licenses happen to both control the same single program, the 7.4 Product can be named based on the program name. If the 6.x licenses both control two or more programs, KSdbConsist has to “guess” what to call the product, and simply chooses one of the License names as the basis for the new Product name.
With the Products window sorted by Name, look at the top for a name like “(License Name 1...)”. The parenthesis causes the product to sort to the top, and the parenthesis and ellipsis are the clue that this name was a guess. You should edit the product and choose an appropriate name.
If PRS has completed its first run, you may have noticed by now that there are far more Products in the Products window than Policies - this is because of the Sassafras-defined Products which have been imported automatically. However, it is easy to see just the Products which come from your 6.x license configuration. All of the Products created by KSdbConsist are put in a Product Folder named “(6.x -> Products)” - so you can filter the Products window to show just these product by clicking to the left of the folder icon, which will add a checkmark and filter the main list. Until you make any other configuration changes, you could instead put a checkmark next to “Referenced”, which for now would have the same effect. Every product created by KSdbConsist is referenced by at least one policy and at least one purchase. Every newly downloaded product definition, on the other hand, is either “Unreferenced” or "Ignored" - there are no policies or purchases for these products.
5. Program Version Mask Changes.
If you open some of the Products created by KSdbConsist, you might notice that the Program lists look substantially different than the Program lists from your 6.x Licenses. If you controlled common programs in 6.x with a Version Mask of “all”, then the mask had to be changed during import of standard product definitions. Standard product definitions tend to distinguish programs by “major version” - i.e. version 1.x of a program will be in one product while version 2.x is in a different product. In order to import proper definitions, the mask of any existing programs might need to be changed. So now for a product that came from a 6.x license that controlled all versions of a program, you might see that the product contains both versions 1.x and 2.x (while the standard imported definitions tend to include just version 1.x or just version 2.x). Products created by KSdbConsist may now contain a strange combination of program variants. If a Sassafras-defined product exists for the product you need to manage, you will probably want to start using the Sassafras-defined product to ensure correct configuration. This will be described later.
6. Logged Product.
When you looked at the top of the Products window you may have also noticed a product named “(6.x -> logged Product)”. If your 6.x data had any logged programs, this special product has been created in order to allow the same programs to be logged (Observed) in 7.4.
Now look in the Policies window, which corresponds to the Licenses window from 6.x. At the top of this window you will likely see two special policies - “(6.x -> deny Policy)” and “(6.x -> logged Policy)”. The first is a Deny policy which we'll look at in a minute. The second policy has a yellow dot icon, which indicates that it is an Observe Policy. This type of policy specifies that programs in the product associated with the policy should have their usage logged.
The rest of the policies should look familiar - they come directly from your 6.x licenses. The names have been modified slightly to replace the word “License” with the word “Policy”. One other change is that 7.4 now has Policy Folders. On the left you will see a folder named “6.x -> Policies” which contains all Policies. At some point you should take a close look at all your Policies and make sure that they are in fact properly defined. This folder will let you distinguish old Policies carried over from 6.x from any new Policies you might create.
Double-clicking any of these policies, you will see a details window that is very similar to the License details from 6.x. The “Policy” pane in 6.x has been renamed “Scope & Action” in 7.4, and the layout has changed a bit, but functionally it allows all the same configurations as before, so long as the Policy action is set to Manage. You will see the familiar Metric, Limit, and other options as always.
There is one important change - where 6.x had a “Restrict to Group” field, 7.4 has a “Scope” field. This new label highlights an essential change in how things are configured in 7.4. In 6.x if a license had a group restriction and someone outside the group tried to launch a program in the license, the program launch would be denied (unless there was another license for the program). In 7.4 if a policy has a group as the scope, and a client outside the group tries to launch a program in the product associated with the policy, the policy simply doesn't apply, and if there are no other policies for the product, the launch is ignored. You can still achieve the 6.x behavior of allowing usage with a group (subject to usage limits) but denying usage outside the group, but this requires a second policy.
One other change is that the “Detachable” checkbox has been removed from the Options pane. The new UI for specifying that usage should be allowed when the client cannot contact KeyServer is to set “Enforcment” to “Relaxed” (as opposed to “Strict”, which denies use if KeyServer cannot be contacted).
8. Deny policy in conjunction with policies that have scope.
Now we can understand the need for the “(6.x -> deny Policy)”. If a program in 6.x was controlled by a license with a group restriction, this needs to be translated to a product with two policies - one Manage policy with a scope, and one Observe policy that is universal, which applies to any launches outside the scope of the Manage policy. If you double-click the “(6.x -> deny Policy)”, you may see multiple products listed in the Products pane. This single Deny policy is sufficient to ensure that any program launches outside of 6.x group restrictions will be denied.
Note that Manage Policies always take precedence over Observe or Deny Policies. As in 6.x, you can specify a search order for the Manage Policies, but Deny and Observe Policies must always come after any Manage Policies.
You should look at each product associated with the deny policy and decide whether the configuration is correct. Denying outside a group in 6.x may have been the wrong configuration. Or, in 6.x you may have created two licenses for a program, where one was configured simply to allow clients outside of a group to use the program without any license limits. If that is the case, you can simplify the 7.4 configuration by associating the Product with just a single Scope limited Manage policy.
9. Audited programs in 6.x.
We've seen that controlled programs are still controlled by policies just as always (with the help of some new product definitions). Likewise, logged programs are still logged via a special product and a special policy. But what about audited programs from 6.x? Most data folders in 6.x had far too many audited programs, so they have not been fully converted (added to products in order to make them appear in audit reports). Instead, they have been simply marked with a flag so they can still be identified in 7.4 via a filter. Look for a filter in the programs window named “ 6.x -> was audited” - this will identify your 6.x audited programs. You can even see an audit report in 7.4 for these programs - right click the filter and select Audit (COMP x prgm). In the Report Builder window, check the "Include Utilities and Ignored Programs" option.
The correct way to include programs in Audit reports in 7.4 though is to define a product that includes the program. If you want a program to appear in Audit reports but never have usage logged, you can add it to a Product that has no Policies. Ultimately you should look through all the programs that were audited in 6.x and define appropriate products if you still wish to see them in audit reports.
You have probably noticed the Purchases window, since it is in the default view. Purchases are one of the important new features in KeyServer 7. When purchases are accurately recorded, KeyConfigure can calculate an up to date count of entitlements, taking into consideration expired entitlements, entitlements reclaimed by Upgrades, etc. The count can then be Reconciled against configured Policies in order to demonstrate compliance. This Entitlement Position based on Purchases will be accurate as long as each purchase is entered in KeyConfigure.
However, with a set of existing Policies which were created before 7, you may not wish to immediately find and enter tens or hundreds of purchases into KeyConfigure simply to show Reconciled Products. Instead, you may want to assume that your Policies as configured at the time of upgrade are correct, and only enter real purchases as you move forward and create new Policies. KSdbConsist creates purchase records so that you will have a choice of how to proceed. During conversion you will get a set of purchase records, one for each Metric for which there is a Policy for each Product. In a simple configuration, this may mean it is as simple as one Purchase record per Policy. It will not be quite so simple if multiple Policies are configured for the same Product. As in the Products and Policies windows, all of the Purchases are in a “(6.x -> Purchases)” folder.
If you open the Purchase details for any Purchase, you will see in the Rights & Conditions pane that each one is a “Synthetic” purchase. Basically this means that the purchase is not a real purchase. Giving a Purchase this License Type lets the Reconcile windows suggest appropriate Actions. You will also see that each Purchase is marked as “Dormant”, which means that while the Purchase is for some number of Entitlements, this count will not be included when KeyConfigure calculates the Entitlement Position for the purchased product.
Select Reconcile from the Tasks menu. In the window that comes up you will see that the purchases created by KSdbConsist are listed but are not being counted since they are Inactive. Every Product (with every Metric) shows 0 entitled, and some number Managed. For more about this window, read the Product Reconciliation documentation. Now right-click on a Product in the Reconcile window, and select Reconcile from the context menu. This will bring up a Reconcile window that is specific to this Product, and shows more detail than the main Reconciliation window.
Notice on the right side of the product specific Reconcile window that there are some Recommendations for how to Reconcile the Product. One of the Recommendations is “Activate Dormant Purchase”. If you select this and click Apply the window will update to show that Entitled now matches Managed. Alternatively, you could select all purchases in the main Purchases window, right-click, and Activate Dormant Purchase, in order to use the Synthetic purchases to show your purchases as fully Reconciled. When a Product is Reconciled, it will no longer shown in the default view of the global Reconciliation Window (This option can be changed using the checkbox at the top of the window). If you do not intend to find all your old purchases and enter them in KeyConfigure, you may want to activate all the Synthetic purchases, so that in the future when you look at Product Reconciliation, you will only see Products for which you have just entered a Purchase or configured a Policy, but where Entitlements don't agree with Policies.
Even if you activate all the Synthetic purchases, you can still enter real purchase information later. Let's say you have a Policy for a 5 Node license for Product A, so of course you have a Synthetic purchase of a 5 Node license for Product A. You activate this purchase and now Reconciliation shows 5 Entitled, 5 Managed. Now you enter the real purchase of 5 Node licenses. If you look in the Reconcile window for Product A, you will now see three Recommendations on the right:
The first two choices continue to assume that the Synthetic purchase is valid, and is a distinct purchase from the newly entered purchase. You want the third choice, Reduce Synthetic Purchase, which will change the quantity of the Synthetic purchase to 0.
11. Look at Sassafras-defined products.
If you enabled PRS when you first logged in to KeyServer 7.4 and the first run has time to complete, you should now have quite a number of Sassafras-defined Products in your Products window. There are a couple of very good reasons to consider using the standard product definitions from Sassafras when you can. First, and most importantly, these definitions are correct to the best of our knowledge. Suite products include all the appropriate programs, and programs have the appropriate version mask. Second, if we discover an error in our definitions we will correct it, and this change will automatically be applied in your data via PRS.
If you filtered the Products window in step 2 to show just the products which were created from your own data, now click the double-check icon at the top of the vertical divider in the Products window. This toggles between custom filter selections, and displaying all products.
A common misconfiguration in 6.x was to forget to set the version mask correctly in a controlled program. For example, you may have had a License for a suite, with all the correct programs in it, but any one of those programs may still all be treating all versions of the program as a single variant. Software which you purchase, on the other hand, is a specific version - when a newer version is released you generally do not have entitlements to the newer version unless you are on a subscription, or you make an upgrade purchase. If a program version mask was not set in 6.x, you will see something like “all... -> 7.x” in the Variant column of the Product Update Wizard (if you choose to "Step Through Details"). This indicates that importing a Product will require the version mask for that Program Family to change from treating all versions as a single variant, to splitting into multiple variants based on the major version. For more about versions masks, see the Program Details documentation. If you import these products, the version mask will change, and whatever Products contained the single program variant will instead contain each major version variant which exists in your data.
Let's go through the steps you will need to complete if you want to use a standard product definition instead of the Product definition based on your 6.x License. In order to facilitate switching from custom-defined products to Sassafras-defined products we have included a new report in 7 named Product Suggestions (PROD). Basically this report looks for overlap between your definition and Sassafras definitions. It is described in detail in the Reports documentation. We recommend that you run this report once PRS has been turned on and added any relevant products to your data. Using the results of the report, as well as "Replace Product References" from the context sensitive menu, you can change your configuration to use as many Sassafras-defined products as possible. If this report lists many products, you may want to right-click "Referenced" in the Products window, then select "Product Suggestions (PROD)". This will only include custom-defined products that are referenced. So then as you replace references to your custom products, if you refresh the report, it will stop showing products you have already dealt with.
12. Look at sample filters
We have come up with a variety of filters, for many of the main windows, which we believe will be useful to most customers. Some of these have been available in prior versions from the “Sample Filters.xml” file. In version 7 they are added automatically to the main windows.
You will get the most benefit from KeyServer version 7 if you can devote some time to cleaning up your configuration. Whether it needs a little clean up or a lot, the upgrade to version 7 was significant and the more attention you can give to your configuration, the more valuable and easy to use your data will become. There are two main tasks you should focus on:
The cleanest way to achieve an accurate configuration is to start with purchases. Look back at what you purchased. For each purchase, make a record in KeyServer. In the New Purchase Wizard, use the search feature to locate product definitions provided by Sassafras - and when needed make careful product definitions of your own. Once you have a Purchase, look through your Policies for a policy which was used for this purchase in 6.x. If you find it, remove the converted Product from the Policy, and replace it with the Product you selected for the new purchase. Also make sure that the Policy Metric and Limit are correct. Ideally you will delete all of the Synthetic Purchases created by the conversion to 7, replacing them with real purchases. Likewise you will delete any Products created during the conversion for which there is a standard Sassafras definition. For products that are not in the Sassafras definitions, you will either verify that the product is correct - containing all the appropriate Application components, each with the proper version mask for the product. Or, you will create a new Product, letting the New Product Wizard guide you through proper version selection, and setting attributes of the product like Publisher and Release Date.