Cautions & Warnings

The component history document includes a brief mention of all significant changes in each release. Read this document for some detail on issues that warrant emphasis or further explanation.

Windows KeyAccess prior to 6.0.3.2 may crash during audit when encountering certain files. (2005-12-15)

Windows KeyAccess version 6.0.3.2 fixes a bug which causes earlier versions to crash when encountering a file during audit that has unusually long information strings in its file property resource. Once KeyAccess has crashed during a login session, all of its license management and reporting functions will be unavailable, so windows clients should be upgraded to the latest client version as soon as practical. To avoid the potential for problems on existing clients using older KeyAccess versions, select such computers in the Computers window of KeyConfigure and use right-click to turn off auditing. Unfortunately, once a computer running an old KeyAccess has encountered one of the problem files during and audit, it will re-try the audit after every boot even if auditing has subsequently been turned off - the only fix in this case is to update the client software immediately.

The 6.0.3.1 KeyAccess client includes support for features that will become available with K2 version 6.1. (2005-08-01)

The next major revision of K2, version 6.1, will include improved support for laptop computers including more flexible deployment options for portable keys and more complete off-line usage logging, upload, and reporting functionality. Additional program recognition and filtering functions will be implemented. These additional features are supported by this 6.0.3.1 client version as a convenience - the new functionality will be immediately available when K2 version 6.1 is released later this year, even for these previously installed clients.

Mac KeyAccess versions before 6.0.3.1 do not distinguish Acrobat Pro from Acrobat Reader. (2005-08-01)

For Macintosh client computers using KeyAccess version 6.0.3.1 or better, there is a special case added that will distinguish Adobe Acrobat Pro (identified as "CARO") from Acrobat Reader (identified as "caro"), even though they actually have the same program stamp ("CARO"). In prior versions, these can only be distinguished by size. Note: KeyAccess 6.0.2.6a is the latest version available for Mac OS 9, so this and other new features are not supported for Mac OS 9.

Windows clients prior to 6.0.3 may fail to manage program usage on non-mapped network drives.(2005-06-01)

When a program is stored on a network drive that is mounted without being mapped to a drive letter, the previous windows client version, KeyAccess 6.0.2.8, will fail to control or report program launches except for "keyed" executables. If you are logging or controlling un-keyed programs that might be launched from a "non-mapped" shared volume, the KeyAccess client software should be updated as soon as possible to version 6.0.3 or better.

The KeyAccess version 6.0.3 or better should be used on Mac OS X 10.4 ("Tiger") in order to avoid possible un-reliability, including possible KeyAccess crashes. Even if an older version of KeyAccess appears to work on some Mac OS X 10.4 systems, it may occasionally not be initialized correctly at user login which may lead to unpredictable behavior and in-accurate program logging or control. For Mac OS 10.3 and earlier, the upgrade to the latest KeyAccess client version is also recommended.

Mac OS X "packaged" installer can be customized for use with deployment tools. (2005-06-01)

The folder "/Miscellaneous/Mac OS X Extras/" in the 2005-06-01 image includes "packaged" installers (.mpkg) for Mac OS X clients. The packaged installers contain the same client components as the Vise installers in the main "/Installers/Client Installers" folder. Read the help document, "Automated Client Deployment", for information on deployment strategies, including customization options for the client installer.

Mac OS X clients prior to 6.0.3 may invalidate portable keys with daylight savings time change. (2005-06-01)

Note: the final version of KeyAccess for Mac OS 9 is 6.0.2.6a. This Mac OS 9 version does not have the daylight savings bug.

Shadow installations using version 6.0.2.8 of the KeyServer component fail to provide service. (2005-03-24)

The KeyServer component 6.0.2.8 (server component for all platforms from the 2005-03-01 image) does not behave correctly when used as a KeyShadow - e.g. , when installed with a "shadow.lic" instead of a "server.lic". You should upgrade any shadow installations using the latest server installers, 6.0.2.9 or better. The KeyServer can also be upgraded to this version (although this is not essential).

KeyAccess versions before 6.0.2.8 do not report basic hardware information unless audited. (2005-03-01)

For client computers using KeyAccess version 6.0.2.8 or better, the basic hardware profile will be reported to KeyServer version 6.0.2.8 or better, regardless of the software audit settings. Prior versions of KeyAccess will only report the basic hardware profile as part of a full software audit so perhaps never if software auditing is turned off.

Mac OS X client, KeyAccess version 6.0.2.4, may hang when booting offline. (2004-10-01)

Under some circumstances, KeyAccess version 6.0.2.4 may hang when booting off-line due to failure of the KeyServer DNS name to resolve. Install KeyAccess version 6.0.2.5 (or better) to avoid the possibility of this problem.

Remote administration of KeyServer version 6.0.2.5 uses both UDP and TCP ports 19283. (2004-10-01)

UDP port 19283 has always been used by the KeyServer host to support connections from the KeyConfigure admin component (and from clients). Beginning with version 6.0.2.5 of KeyServer and KeyConfigure, TCP port 19283 is also required to support the KeyConfigure admin connection (formerly TCP was only required to support KeyConfigure's reporting functionality).

The linux server process requires glibc library version 2.3 or better. (2004-10-01)

Beginning with the 2004-10-01 image, older versions of the glibc library will prevent the ks process from starting up.

Windows Firewall, enabled by Service pack 2 for XP, may interfere with K2 server & client. (2004-09-01)

Network communication between server, client, and admin components of K2 depends on specific UDP and TCP network ports.. The default firewall rules enabled by installing Service Pack 2 for Windows XP will interfere with this communication.

The latest Windows client installer (KeyAccess version 6.0.2.4 or better), will install the necessary custom firewall rule for the keyacc32.exe component.

The Windows Firewall control panel must be used to add custom rules for the KeyServer host (or KeyShadow) as explained in the installation instructions and in the online help document, "Firewall Setup".

On Mac OS X, a corrupt preference file may make portable keys inaccessible. (2004-08-01)

If portable keys are used on Mac OS X clients, you should upgrade to the latest KeyAccess as soon as possible (version 6.0.2.3 or better). This will protect against loss of access to portable keys after a reboot due to possible corruption in the KeyAccess preference file. All Mac OS X clients should eventually be upgraded in order to avoid the preference file corruption bug, even though such corruption only has severe consequences for users of portable keys.

Program mask changes made with KeyConfigure prior to 6.0.2.2 may prevent launches. (2004-07-01).

When a controlled program is split into multiple distinct variants (by sliding the version mask in the Program Details window), client computers may not be correctly updated with the newly created program variant definitions and their corresponding control rules. In some cases, this may result in a program which satisfies the old variant definition being prevented from launching. KeyConfigure 6.0.2.2 avoids this problem by instructing clients to update all cached control rules whenever any configuration change effecting program control is made.

Problems with a blocked program launch on a particular client will then be immediately cleared by a client reboot, by sending a bulletin message to the client, or by waiting about 15 minutes for all the update requests to be delivered.

In some cases when there are restricted permission issues or multiple user accounts, it may also be necessary to update the client software to KeyAccess 6.0.2.2 or better as documented below. Of course in all cases you should install the latest client when convenient.

Multiple logon accounts using Windows KeyAccess prior to 6.0.2.2 may prevent launches. (2004-07-01).

With the Windows KeyAccess client prior to version 6.0.2.2 , the operating system default (or customized) registry permissions for non-admin accounts may interfere with a client's ability to reliably learn license management policies. Potentially, the ignore/log/control instructions for a particular program run under a particular user account may not be honored. To avoid this potential problem, starting with KeyAccess version 6.0.2.2, registry settings are created and stored with write access requested for all accounts.

KeyAccess Setup, version 6.0.0.9, running on Mac OS X may eventually prevent program launches. (2004-04-04).

Version 6.0.0.9 of KeyAccess for Mac OS X introduced a new inter process communication protocol. A bug in the cleanup routines results in the eventual blocking of all communication when KeyAccess Setup (the configuration interface - not the client process) is left open for a long period of time. The same bug means other programs like KeyVerify and formZ, which directly use the ks API for inter process communication, can also lead to blocked launches if left running for a long time. Quitting these programs resolves the problem - better yet, upgrade the KeyAccess client install to a newer version.

Mac OS X KeyAccess versions prior to 6.0.0.9 may use excessive cpu cycles when offline. (2004-03-20)

When a Macintosh computer (e.g. a powerbook) is disconnected from the network, the KeyAccess client software may continually waste cpu cycles trying to find the KeyServer. Any Mac that might not have a continuous network connection should be upgraded to KeyAccess version 6.0.0.9 or better.

KeyServer versions prior to 6.0.0.9 may be unstable when logging more than about 1000 programs. (2004-03-20).

When the number of distinct program versions discovered by KeyServer remains below 2048 this bug has no effect. But the Programs window aggregates many program versions into each program record that it displays, so it is difficult to estimate exactly when the bug threshold will be reached. If you have designated a significant number of Program variants as logged, it is recommended that you upgrade to KeyServer version 6.0.0.9 as soon as convenient.

Clients normally receive at KeyServer logon time a hint list of shadow addresses to try in case there is trouble reaching the KeyServer. In KeyServer version 6.0.0.8 and some previous versions, this hint list was not sent until later (if ever). If you are using the shadow feature, you should upgrade KeyServer to version 6.0.0.9 or better.

External Reports account was enabled by default in KeyServer versions prior to 6.0.0.9. (2004-03-20)

The External Reports account was enabled with default password "Sassafras". For a better data privacy, in KeyServer versions 6.0.0.9 and better you must explicitly assign the password "Sassafras" or some other password before the account is enabled. If you are only using internal reports, this account is best left disabled. When using or upgrading an older version, you might want to assign a different password using the "KeyConfigure Accounts ..." menu item.

KeyServer 6.0.0.9 has a new field. If exporting, external tables should be updated. (2004-03-20)

A new data table and fields have been added to KeyServer's internal databases with version 6.0.0.9 (released in the 2004-03-20 image).

There is a new table called KSComputerDivisions
KSProgramFolders has a new field: folderColor
KSComputers no longer has the computerPrimaryGroup field
KSComputers has three new fields: computerBaseAudit, computerAcknowledged, and computerDivisionID

These changes have no external effect unless you are exporting data tables for analysis on a remote, external, database server. Even if you are exporting, reports that don't use the new table or fields, will continue to work as always after upgrading to KeyServer 6.0.0.9. However, in order make use of the new reports (and to avoid confusion in the future) it is recommended that you change the external tables to match the new format. When convenient, you should back up your exported database and then perform the following steps:

Note: the new KeyConfigure built in reports, “Audit Baseline” and “Audit Delta” take advantage of the additional data so these require KeyServer 6.0.0.9 or better.

Default purge of old usage records limits the size of Usage Database for faster reports. (2003-12-16)

By default, records of program usage occurring prior to a 5 or 10 weeks in the past are purged from the Usage Database so that reports will not be slowed down by massive amounts of old data. With the latest versions of KeyServer and KeyConfigure, reporting performance has been further optimized so that a longer history of usage is now practical. The new default is to purge usage records older than 30 weeks (Note: an upgrade install will not change the existing value). Depending on the number of programs being controlled or logged, the number of clients supported, and how fast your Admin and Server computers are, you may want to set the "Clear Local Usage Data After..." to a different value – change this setting from KeyConfigure's Admin > Exporting... dialog. Use the context menu for Help in this dialog if you also want to configure the export of usage and other databases for storage and queries hosted on an external database server.

In order to optimize reporting performance when KeyConfigure 6.0.0.8 is running under Mac OS 9, it was necessary to disable some "self send" functionality – the Reports menu will disable the primary reports (leaving only "Legacy Reports") when the connected KeyServer is hosted on the same Mac OS 9 computer that is hosting KeyConfigure. Caution! Versions 6.0.0.5 through 6.0.0.7 do NOT disable the primary reports – instead the Mac OS 9 KeyServer host computer will hang if these reports are run on the same computer. Conclusion: if you are hosting KeyServer under Mac OS 9, be sure to run KeyConfigure from a second computer whenever you want to run Reports.. A KeyServer hosted on Mac OS X or Windows will not have this limitation and may also give better KeyConfigure responsiveness in general.

When using KeyConfigure 6.0.0.5 with KeyServer 6.0.0.5, the computers window will show a new pane on the left called "Divisions". Similar to the Programs window, newly discovered computers show up with a pink font and are placed in the Discovered category. A right-click on discovered lets you set login "Full" or login "Prohibited" as the default. Details are in the Help documentation for the Computers window and an example is demonstrated in Getting Started. Note: when KeyConfigure 6.0.0.5 is used with KeyServer 6.0.0.4 or older, you won't see these new features (and due to a bug, you won't be able to create new computer filters - upgrade the KeyServer to 6.0.0.5 or better!).

Mac OS X 10.3 (Panther) requires KeyAccess 6.0.0.5 client software. (2003-11-12)

When a Mac OS X 10.3 computer is set up with multiple accounts using "fast user switching", you must use KeyAccess client version 6.0.0.5 or better. The previous version will work under Panther when only a single client logon is active at a time (no fast user switching) but versions 6.0.0.3 and older are not supported at all on Panther. Note: when multiple user accounts are simultaneously in use with a connection to KeyServer, you may notice in the Users window of KeyConfigure that a single computer is listed in duplicate for each additional user account logged in. A bulletin message directed to any user of this single computer will be directed to the foreground user only.

Appletalk client connections not supported by KeyServer hosted on Mac OS X. (2003-11-12)

Apple is phasing out compatibility testing and support for AppleTalk in its newer versions of Mac OS. It is best to use IP for all KeyServer client connections with a DNS name which resolves to the KeyServer IP address. If you still need to support AppleTalk clients, host your KeyServer and KeyShadows on Mac OS 9, Netware, or Linux hosts.

Win 2000 security patch KB824141 and SP2 for Win XP disable KeyConfigure login screen. (2003-10-15)

After applying the Microsoft security patch KB824141 on Windows 2000, any KeyConfigure prior to version 6.0.0.5 (2003-11-12 image) will generate repeating characters when trying to enter text in its login screen. Upgrading Windows XP to Service Pack 2 produces the same problem. You must upgrade KeyConfigure to version 6.0.0.5 or better.

The usual default computer ID is based on the network hardware address. This ID may become confused by cloning duplicate computers from a master image using an imaging utility (such as Symantec's Ghost). This may cause up to 3 computer records to be generated for the same computer (identified by hardware address, computer name, and OEM serial number). To avoid this problem, use the latest windows client (version 6.0.0.3 or better) for the master and all clones.

To clean up from bad data generated by a ghost image containing an older client version:

Alternatively, you can uninstall the old client software and install the latest version on all clients (you must uninstall – updating alone is not sufficient). Then simply delete the Machine Id Database from the KeyServer Data folder and restart KeyServer process. At the bottom of the Computers window in KeyConfigure, ctrl-click on the word "refresh" to wipe out KeyConfigure's cached records. Computers will be re-discovered and added to the window as they logon on to KeyServer.

If your KeyServer has special "remote function" support installed for the formZ program (from www.formz.com), be sure to upgrade their files to the latest versions (formZ_KS_WIBU.lic and rf_VTVS). Otherwise, the KeyServer may consume 100% cpu and launching an old version of the formZ program will crash the KeyServer process! Also, when running formZ on Mac OS X, be sure to upgrade the K2 client (KeyAccess) to the latest versions in order to avoid very slow launches.

Field definitions for exported tables have changed with the release of KeyServer 6.0.0.2 in the 2003-08-26 image! This change has no effect unless you are exporting data tables for analysis on a remote, external, database server. It does not effect the default KeyServer setup which uses its own internal databases and built in reports.

If you are using the Export feature with KeyServer 6.0.0.0 or 6.0.0.1, then before exporting any data from any KeyServer version 6.0.0.2 or newer, you must delete the exported KSAudits and KSPools tables and re-export from the new KeyServer version:

Starting with KeyServer version 6.0, when a client computer (e.g. 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 6.0 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!

Previous KeyServer versions 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. Be sure to follow the instructions in the Upgrade Chapter from the Getting Started manual in order to avoid losing support for client access or loosing support for controlled software that you have already deployed under KeyServer 5.x control.

Third party dongles and support files may need replacement when moving to new host. (2003-06-30)

Some software publishers (e.g. formZ) supply custom license certificates and/or hardware keys ("dongles") to provide secure license enforcement for their products under KeyServer management. When KeyServer is moved to a new host or operating system, these third party support files may need to be replaced with platform specific versions. Contact the third party vendor for details.

Upgrade from KeyServer 5.x requires a 6.0 license and possibly client upgrades. (2003-06-30)

Attention KeyServer 5.x Administrators: do not update an existing 5.x KeyServer unless you have received a K2 v6.0 server.lic. The 6.0 KeyServer will not run with a 5.x license file! Please send us mail or give us a call if you'd like to move to K2 v6.0 right now.

KeyServer will support a mix of KeyAccess 5.2 and 6.0 client versions, but it will reject clients running KeyAccess versions prior to 5.2 by default. Of course auditing is only supported by the 6.x client versions.

Note: comments above concerning the KeyServer component will generally also apply to a KeyShadow install. However, KeyServer maintains crucial license management data files (in the KeyServer Data Folder )- on a KeyShadow these are cached copies and can be discarded.