K2 – Getting Started Installation Guide & Technology Overview

Upgrades

     • Additional Clients
     • Upgrade KeyServer
     • Move KeyServer – New Host
     • Upgrade KeyConfigure
     • Upgrade KeyAccess
     • Upgrade KeyShadow
     • Upgrade or move KeyReporter

This document documents the procedures for adding clients and upgrading previous versions (5.0, 5.1, 5.2, 6.0, or 6.1.x) to the latest 6.1 release. The earlier section, “Web Updates”, explains how to get the compressed archive for the latest image from the web. Check the readme file in any new archive for special warnings or important notices.

Upgrading a Client, the Admin software, the Reporter, or the Server itself from a previous 6.1 installation is easy: run the appropriate installer from the latest 6.1 image. Assuming that the components from a previous install remain in their default location, the installer will automatically replace the existing components.

In all cases, the installers do not change the essential configuration data:

• Clients will retain their connection information (and portable licenses, if any)
• KeyServer will retain its license management data
• KeyReporter will retain its saved web reports, templates, and schedules
• KeyShadows will retain their setup info (pointing to KeyServer)
• KeyConfigure will retain its templates & preferences

If a component is “busy” or “in use” it will be moved aside to make way for the new version to be put in place. The new component won’t actually execute until you quit and re-launch the component you are installing or until you restart the computer.

The sections below give some important details, especially for upgrading KeyServer itself.

Additional Clients

In order to increase the number of clients supported by an existing KeyServer, you will need a new "server.lic" file from Sassafras that is configured with an increased client count. Move the old server.lic out of the KeyServer Data Folder and replace it with the new one - then stop and restart the KeyServer process.

Changing from an “eval” installation to a full KeyServer installation is accomplished in essentially the same way. Simply place your custom server.lic file into the KeyServer Data Folder. Then stop and restart the KeyServer process.

When the licensed maximum number of client records have been created in KeyServer's Computers window, any newly discovered clients will be assigned Login status: “Prohibited”. Even when you upgrade with a license certificate having an increased client count, these records will remain prohibited! Double click on the word “Prohibited” (Computer window Login pane) to display just these records in a separate window. Then ‘select all’ in this window and drag the selection onto the word “Full” (Computer window Login pane) - this will activate these computers for a full login when next started (assuming the new license certificate has a sufficient client count for all of them).

When upgrading your license count, it is probably a good time to also update the server components. Use the KeyConfigure "check versions" button (in the "About KeyConfigure" menu) to see if your components are up to date. From the Help menu also check the online Component History and the Warnings document for specific bug fix information.

If you have a KeyShadow installed (in order to support keyed program launches in case KeyServer is temporarily unreachable), you should update its shadow.lic file whenever you increase the client count of your KeyServer. Instructions are detailed in the “Upgrading a KeyShadow” section.

Upgrade KeyServer

The change from an evaluation KeyServer to a full KeyServer (same version) is described in the “Additional Clients” section (above).

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. 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 controlled programs is: "allow usage when KeyServer 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:

• first quit KeyServer and archive the entire Server folder to a backup location. If anything goes wrong with the update, you can then revert to the archived backup.
• always check the Upgrades and Warnings document and the Component History for important cautions particular to the version you are about to install.
• if your KeyServer is controlling keyed as well as un-keyed programs (or the "allow usage when KeyServer not available" default has been turned off for some programs), you should make sure there is a working KeyShadow process to take care of keyed program launch requests during the upgrade outage.
• if you have installed KeyShadows, plan on also upgrading these to the same KeyServer version ASAP.
• you may want use the "KeyAccess Version Control..." menu item in KeyConfigure's Admin menu to warn or block older client versions.*

*Even though KeyServer version 6.1 will support clients using KeyAccess versions back to 5.x, the latest features and improvements are only supported by 6.1 clients. In particular, the auditing feature is not available at all in KeyAccess versions prior to 6.0, and there have been several feature improvements and bug fixes since the initial 6.0 release. If practical, before upgrading it is best to make sure that clients are running at least version 6.0.2. You can use the "KeyAccess Version Control..." menu item in your old KeyConfigure to set a custom warning message for older KeyAccess versions and to disable very old versions. The warning and disable thresholds you set will be preserved by the upgrade to 6.1.

The installer for KeyServer 6.1 also includes an install of "KSdbConsist" - a utility which is used to check, repair, and reformat configuration and data files from an existing KeyServer Data Folder. The KSdbConsist utility creates a report named "fixed.ksr" which documents any repairs. This report along with a backed up original of repaired file(s) is saved inside the Backup sub-folder within the KeyServer Data Folder. The report file has file extension .ksr - use KeyConfigure to read it.

KeyServer Upgrade Essentials - data file formats, software components, and KSdbConsist

The comments in this section are stated by way of explanation, since the K2Server installer automates all the necessary steps as detailed in the following sections.

File formats and database names have been changed with each major upgrade of KeyServer. Support for UTF-8 character encoding in 6.1 requires translation of several files. 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 can also be extracted from the installer and used at any time to check data integrity of either 6.1 or 6.0 formatted data files.

When run within the server installer, KSdbConsist will always transform 6.0 formatted data files found in the standard install location into 6.1 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.

Instead of the automated upgrade procedures described below, you could move an existing KeyServer Data Folder out of the standard location and run KSdbConsist to check for needed repairs - choosing 6.1 output format. Then when the K2Server installer is run, it will create a vanilla "evaluation" installation in the standard location (since the existing data folder was moved aside). Now if you move the data files (e.g. top level files, not including sub-folders) from your repaired/upgraded data folder back to the new KeyServer Data Folder (replace the ones created by the evaluation install, being careful to mimic ownership and read/write privileges) then the upgrade of software components and reformatting of data will have been accomplished.

Unlike the Windows and Macintosh installers, the linux rpm installer for KeyServer components does not automate the upgrade process. The linux command line utility, “dbconsist” must be run manually to transform old format KeyServer data. Even though automation does not apply to the linux installer, the general comments and cautions described below are still worth reading. For more information, see the Linux section of the OS Details document.

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 proceedure 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 proceedure on the the active KeyServer.

Minor Upgrade - from 6.1.x to 6.1.y

This upgrade simply requires running the new KeyServer installer "on top of" the existing installation. The installer does not back up any of the existing data files (they are left in place) nor existing components (they are over-written).

1. Run the K2 server component installer to update the existing KeyServer components..

The "KSdbConsist" utility will be launched from within the installer, so you have the option of checking database integrity as part of the upgrade process. If KSdbConsist finds database errors, it will backup any file before making a modification or repair - the original will be moved into the Backup Folder, a sub-folder of the KeyServer Data Folder. When doing a minor upgrade, it is recommended that you take the time to let KSdbConsist complete its check of all data. But even if you cancel the KSdbConsist run, the KeyServer components will still be upgraded since a "minor" upgrade does not require any data format changes.

2. Restart the KeyServer service.

In order to activate the new software version, restart the KeyServer process - or just re-boot the host computer.

Major Version Upgrade - from 6.0 or 5.x to 6.1

Several new features and interface changes are introduced in K2 version 6.1. Even if you are a seasoned K2 administrator, it will be wise to take the time to run through the Quick Setup and Demo Tour. Also consult the Changes from 6.0 to 6.1 document to read about important differences in terminology and functionality.

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.0 or 5.x but if you are upgrading from version 5.x, first read the following section, "special notes before upgrading from version 5.x".

The version 6.1 KeyServer requires a license certificate, server.lic, that supports version 6.1.

With only a 6.0 server.lic in place, an upgrade to KeyServer 6.1 would default back to the eval.lic which has support only for a small number of clients. When you obtain your 6.1 server.lic file via e-mail from Sassasfras Software, it will be most convenient to immediately install this file in your existing KeyServer Data Folder since it will also support your older KeyServer version. Then the necessary license file will already be in place when the software components that require it (e.g. 6.1) are first installed.

The version 6.1 KeyServer requires version 6.1 of the Admin component, KeyConfigure.

An older KeyConfigure (e.g. version 6.0 or 5.x) will not connect to an upgraded 6.1 KeyServer. Before upgrading the KeyServer to 6.1, it will be most convenient to first install KeyConfigure 6.1 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 (e.g. the old "Admin" folder will be renamed to "6.0 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.0 or 5.x, the "K2Server" installer will set aside the existing server folder (found in the standard install location), and change its name appropriately (e.g. "6.0 Server BACKUP"). The moved aside data files will be used as the basis for creating reformatted data files in the new KeyServer Data Folder (in the standard install location). 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.0 Server Backup") rather than being copied. 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.

The version 6.1 KeyServer requires new formats for several of its data files.

The installer will import the Machine ID Database records into a new format "Computer Database". The old "Usage Database" will be converted into two new 6.1 format files: "Usage Log" and "Usage Index Database". By default, the upgrade installer suggest not upgrading the Audit Database since it will be rebuilt when clients upload their individual audit information. You also have the option of discarding old Usage data rather than converting it. License certificate files from the old data folder will also be copied and then 6.1 KeyServer components will be installed. The new 6.1 KeyServer data formats will require about half the space of the older formats.

If your 6.0 KeyServer is configured to export its databases to a remote database server, you must take special precautions to avoid re-exporting duplicate records after the upgrade and to avoid mismatched program identifier information. Before upgrading, contact Sassafras for instructions on how to avoid export problems.

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 Database 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 "Active Controls" or "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 6.1, 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 in its standard install location 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 6.1 which you should be aware of. Any programs set to Ignored in 6.0 will still be called "Ignored" in 6.1 provided they were also set to "don't audit". Usage will not be logged nor will those programs show up in Audit reports. On the other hand any Ignored programs that were set to Audit will be converted to the new 6.1 category of "Audited" -- usage of these programs will not be logged but the programs themselves will appear in audit reports. Note that in both cases there is no change in behavior, just a reclassification of one category into two. You should not be surprised if most of your "Ignored" are called "Audited" in 6.1. These and other changes are described on the "Changes from 6.0 to 6.1" page, which KeyServer 6.0 administrators should read.

Here are the steps for upgrading to version 6.1 from version 6.0 or 5.x. Note: unlike the minor upgrade described above, 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 6.1.

The new server.lic file is sent via e-mail when you purchase the 6.1 upgrade. The text line "license range=5.0-6.1" in this file means that it will enable any KeyServer version from 5.0 through 6.1 - 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 C:\Program Files\Sassafras K2\Server\ - this is where the installer looks for any previous install.

The standard install location on Macintosh is /Library/KeyServer/ on the boot drive - this is where the installer looks for any previous install.

2. Launch the K2Server component installer - this will run the KSdbConsist utility to check data files.

If a data file needs repair, it will first be duplicated into the Backup Folder (inside the KeyServer Data Folder) where KSdbConsist will also create a report that documents the repair. 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 6.1 to connect and verify settings.

Use your old KeyServer password - it has been preserved in the upgrade to 6.1. KeyConfigure will present a dialog, “The default Program Rules have not been installed yet... ”. These are the Windows and Mac classification rules which you should be familiar with from running the the Getting Started tour - go ahead and let KeyConfigure install them. You can always change them later.

Special notes before upgrading from 5.x

There are many changes to both the management interface and functionality when upgrading to 6.1 from KeyServer 5.x . Be sure to read all of the cautions in this section. Before proceeding at all you should familiarize yourself with K2 – be sure to run through the Quick Setup and Demo Tour!

5.x Upgrade Caution: Starting with K2 and KeyServer version 6, when a client computer (i.e. a computer with KeyAccess installed) first logs in to KeyServer, a client record is created in the Computers table in order to support the new K2 features (e.g. computer hardware and software audits). Your custom License Certificate (server.lic file) specifies the maximum size of this table. As soon as the table becomes full, no service will be provided to additional clients regardless of how many computers are actually connected to the KeyServer currently!

KeyServer versions before K2 (e.g. KeyServer 5.x) have always had the same maximum client count specified in the License Certificate (server.lic file) but without a persistent Computer client table, it was easy to over deploy the client software. In K2, records are added in the Computers window as “Full” or “Basic” clients (clients which are allowed to Login) until your licensed KeyServer maximum is reached . Any additional client connection attempts will be greeted with the message: “You do not have permission to login”. A new entry will still be added to the Computers list but only as a “Login Denied” item – it won’t count against your licensed total for KeyServer clients. Note: when client computers become inactive at your site (e.g. they have been deployed elsewhere, replaced, disposed of, etc.), you can delete their corresponding records from the Computers window in order to make way for new clients. Alternately, you can drag computer records into the “Prohibited” login type in the Computers window whenever you want to prohibit future logins. The Computers window shows the last login time for each client, so any abandoned client records are easy to sort out and deal with.

Before upgrading from 5.x to KeyServer 6.1, run the Client report against your existing 5.x KeyServer logs. This will show you the actual number of unique clients you will need to support with your version 6.1 server.lic. KeyServer 5.x did not create persistent client records, so you may discover that you have inadvertently installed more clients than are actually allowed by your License Certificate. Make sure you have a valid 6.1 License Certificate (server.lic) with support for a sufficient number of clients. Also be sure to follow the steps below in order to avoid losing support for controlled software that you have already deployed under KeyServer 5.x control.

The upgrade to K2 from KeyServer 5.x is similar to the upgrade from 6.0 but with a preceding step (step 0), and some configuration steps that must be done using KeyConfigure after the installer has finished.

0. Move the folder containing version 5.x KeyServer to the new standard location.

The KeyServer 5.x folder is normally found at "C:\Program Files\KeyServer 5.x\". In order to prepare for the upgrade from the previous install, this folder must be renamed and moved into the new standard location for K2. Create a new folder "Sassafras K2" in Program Files, rename the "KeyServer 5.x" folder to "Server", and move it inside the "Program Files\Sassafras K2\" folder. The resulting "C:\Program Files\Sassafras K2\Server\" will be used as the basis for the upgrade. The installer will then move this folder aside, giving it the new name "C:\Program Files\Sassafras K2\5.x Server BACKUP\".

On Mac OS X, the standard location for any version of KeyServer is /Library/KeyServer/ . The installer will use whatever previous version is found here as the basis for an upgrade. Note: there is normally an alias file named "Server" located in "/Applications/Sassafras K2/" that points to "/Library/KeyServer/".

1-3. Install a "server.lic" / run the K2Server installer / restart the KeyServer process.

These three steps are described in detail in the previous section, "Major version upgrade..." - be sure to read the entire section including comments concerning Admin requirements.

4. Connect with KeyConfigure 6.1 using the account name “Administrator” and the default password “Sassafras”.

Your old 5.x password is not preserved by the upgrade from 5.x to version 6.1 !

After running the upgrade install from 5.x as described in steps 1-4 above, there several things to check using the KeyConfigure interface:

• Run the report called Control (LIC x prog) and carefully inspect the output. Check that all of your old license control information has been imported and is now configured correctly. Double click on each license in the Licenses window. You may need to fix up some details for custom licenses and you will probably want to reorganize some license properties using KeyServer 6.1’s greater flexibility
• Check the "License Details" for each line in the Licenses window. Every item listed is functionally a "suite" – it can control one or many programs. Each "active control" from a 5.x KeyServer is automatically placed inside a “suite wrapper” as it is imported into K2. Suite licenses imported from the 5.x Active Controls window are imported without being wrapped - their "suite members" are now displayed inside the License Details window (under its Programs pane).
• If your KeyServer 5.x was configured to use its node locked feature for a license, the node list must be re-built. By default, such a license is imported as "Computer Limit ..." license with the "Auto-add up to the limit" feature enabled - nodes will automatically be added as they launch a program controlled by the license. You can also manually rebuild the node list. Use KeyConfigure 6.1 to drag a computer from the Computers window and drop it into the "Computer Node List..." for the particular license.
• Previous versions of KeyAccess, version 5.2 and earlier, are compatible with KeyServer 6.1 – but without support for the new auditing functionality. Note: when multiple network connections are used (wired, wireless, dialup, docking station), the old 5.x client versions may generate duplicate records in KeyConfigure's Computers window. This is just one of several reasons to bring all old clients up to date as soon as practical.
• If your old KeyServer 5.x was being shadowed by KeyShadow installs, these should be replaced with the 6.1 software as soon as possible (see below). Also check the imported ip shadow hint list (“Shadows” menu) to make sure it is valid – if there is no 6.1 KeyShadow installed at a listed ip address, then delete the entry from the hint list.

Move KeyServer - New Host

The data files (but not the software components) contained in the KeyServer Data Folder are the same regardless of which operating system is hosting the KeyServer process. However, some authentication and export methods are supported only on certain hosts, so check the OS Details documentation before migrating to a different host operating system.

Follow the steps below to first copy your custom data and then to replace the OS specific components:

1. Run the appropriate K2Server installer for the new host.

This will create a KeyServer Data folder in the standard install location for the host platform. Don’t bother starting the KeyServer process.

2. Copy the old KeyServer Data Folder

Find the newly created "KeyServer Data Folder" in the standard install location and replace it with a copy of your old “KeyServer Data Folder” duplicated from your old host computer - make sure the old KeyServer process is stopped before copying its data!

3. Run the K2Server installer a second time.

This will launch the KSdbConsist utility to repair and reformat the old data files as necessary - any originals that need repair or reformatting will be moved into the Backup Folder (inside the data folder). This second run of the installer will also overwrite software components in the copied data folder with the correct binary versions for the new host platform.

4. Startup 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.

*The instructions are essentially the same even if you are simultaneously upgrading from a 5.x or 6.0 KeyServer, but before starting up the new KeyServer you must install a new “server.lic” file that supports version 6.1. This is described in the section, “Upgrading KeyServer”, where other important details and cautions concerning an upgrade are also mentioned.

If your clients are using a DNS name to point to the KeyServer, you can simply update the information in your DNS server to follow the KeyServer to its new host address. Otherwise, clients will have to be re-configured using KeyAccess Setup. If you are using shadows, you will also need to run KeyConfigure and create a new shadow license (containing the new server address) - use this to replace the shadow.lic on each of your shadow computers.

Check the firewall documentation and make sure that firewall settings are correct to allow access from all desired client locations and any shadow locations. 

Upgrade KeyConfigure

Before running the Admin installer, quit KeyConfigure. The version 6.1 Admin installer looks for the “Admin” folder inside the “Sassafras K2” folder. If the Admin folder already contains KeyConfigure 6.1.x, the installer simply updates all the 6.1 components. If the installer finds KeyConfigure 6.0, it moves the old Admin folder aside, (e.g. renaming it to "6.0 Admin") and creates a new Admin folder with the latest components.

KeyConfigure 6.1 will only connect to KeyServer 6.1. If you need to also manage a version 5.x or 6.0 KeyServer, you will need to keep the matching 5.x or 6.0 KeyConfigure version.

If you have multiple versions of KeyConfigure (or other K2 components) installed, you should check which instance of the target program any shortcut in the Start menu resolves to. To avoid confusion among KeyConfigure versions, it may be safest to double click on a particular "keycfg32.exe" file in Windows Explorer, rather than trust the program menu. You should also double check that there is just one entry for KeyServer in the Services control panel and that it does not have a Startup shortcut.

Note: by default, KeyConfigure 6.1 no longer displays "Run Legacy Report ..." in its Reports menu. In order to regain access to reports that depend on the old text format log files (e.g. reports like "download" and "summarize"), consult the Important changes from 6.0 to 6.1 documentation.

Upgrade KeyAccess

One of the paramount goals in designing K2 and the KeyServer 6.1 process has been to maintain backward compatibility with older versions of KeyAccess as well as copies of programs that have been keyed. After upgrading your KeyServer to version 6.1, you do not need to upgrade all of your clients immediately. KeyServer will tolerate a mix of KeyAccess 5.2, 6.0, and 6.1 client versions, so you can update your users’ systems gradually when convenient. If you want to use the K2 audit functionality, however, your users will need to run KeyAccess version 6.0 or better. In particular, enhanced computer hardware profiles (including display resolution and manufacturer) and better protection against duplicate computer records require KeyAccess 6.1. Of course it is best to keep your clients up to date with the latest KeyAccess version to avoid wasting time on bugs that have already been fixed.

Mac OS X running on Intel processors requires KeyAccess version 6.1.

KeyAccess version 5.2.x does not tolerate multiple network interfaces (e.g. wired versus wireless) very well. The Computers window in KeyConfigure will show two records for a single computer and usage activity may be alternately charged to one or the other record. 6.0.x clients (especially early 6.0.x clients) may have similar problems. For this and other important reasons, windows client computers should be upgraded to the latest KeyAccess version 6.1 ASAP.

Consult the Upgrade Warnings and Component History for specific documentation of bug fixes and known isssues. Note: support for KeyAccess clients older than version 5.2 is turned off by default (in the KeyConfigure Admin menu - "KeyAccess Version Control...").

Upgrade KeyShadow

Shadows can be hosted on any platform that can host the server process – a shadow is just a server install that uses a shadow.lic license file in place of a server.lic file. When you upgrade KeyServer to version 6.1 from 6.0 or 5.x, you should also upgrade all shadows to version 6.1 as soon as possible. Old shadow versions may give some degree of partial service, but they cannot mirror any of the new KeyServer features and may not even support old features reliably when shadowing the 6.1 KeyServer.

You can use a server installer to install the server components on several computers, but the server.lic must only be installed on one – the rest must instead use a shadow license file, shadow.lic.

Minor upgrade: upgrading a KeyShadow process from an existing 6.1 version is essentially the same as upgrading KeyServer. Run the appropriate server installer to replace components with the latest revisions. The cautious steps to insure against loss of service or data loss when upgrading a KeyServer are not necessary when upgrading a KeyShadow. Except for the shadow.lic file and the installed software components, the contents of the so called “KeyServer Data Folder” on a shadow computer are automatically mirrored from the KeyServer being shadowed.

If the IP address of KeyServer is changed, or if KeyServer’s client count or enabled protocols are re-configured, use KeyConfigure to make a new shadow.lic file and use it to replace the existing shadow.lic files on KeyShadow computers. The new license will require that you enter the first-run shadow password again: follow the KeyShadow password instrutctions from the install document.

Major upgrade: you don’t actually “upgrade” a 6.0 or 5.x KeyShadow installation - just shut down the KeyShadow process and throw away the entire folder KeyShadow folder (e.g. the folder that includes the KeyServer Data Folder containing the "shadow.lic" file). Then follow the instructions for a first time, "clean", install of KeyShadow.

Upgrade or move KeyReporter

The KeyReporter installer simply creates the folder “Reporter” containing the KeyReporter program and supporting components in the KeyReporter Data Folder. When run on top of an existing install, the latest component versions replace the older versions. Any data files (e.g. archived reports, schedules, configuration parameters) are not touched.

To upgrade, just run the latest installer.

In order to move KeyReporter to a new host, first make sure firewall settings on the new host are setup correctly and then:

1. Run the appropriate K2Reporter installer for the new host.

This will create a KeyReporter Data folder in the standard install location for the host platform. Don’t bother starting the KeyServer process.

2. Copy the old KeyReporter Data Folder

Find the newly created "KeyReporter Data Folder" in the standard install location and replace it with a copy of your old “KeyReporter Data Folder” duplicated from your old host computer - make sure the old KeyReporter process is stopped before copying its data!

3. Run the KeyReporter installer a second time.

This second run of the installer will overwrite software components in the copied data folder with the correct binary versions for the new host platform.

4. Startup the KeyReporter service.

In order to activate the new software version, restart the KeyReporter process - use the services control panel or terminal utility or just re-boot the host computer.

K2 - Getting Started