Upgrade: Notes & Warnings  

K2 v6.1 (2008-11-01 Image)

Read this document for some detail on bug fixes or upgrade issues that warrant emphasis, explanation, or might otherwise be overlooked.

Details

Component History(2008-11-01)

In addition to the specific warnings below, always consult the comprehensive list of all important bug fixes as documented in the Component History.

KeyAccess version 6.1.4.2 or better is required on Windows when Terminal Services is disabled. (2008-08-21)

By default KeyAccess is installed on Windows as a service rather than as a startup item. When Windows Terminal Services is disabled (e.g. remote desktop is disabled), prior KeyAccess versions cannot run as service and must be reconfigured to run as a program or updated to 6.1.4.2 (or better). Load times as KeyAccess starts up have also been improved in 6.1.4.2.

Upgrade to Mac KeyAccess 6.1.3.2 or better to fix missing usage reporting of old style executables. (2008-02-01)

A bug was introduced in the 6.1.3.1 KeyAccess version that prevents usage tracking for old style Macintosh applications based on the the CFM format (e.g. Microsoft Office programs prior to Office 2008). This bug is only present in KeyAccess 6.1.3.1 and it does not affect packaged applications - these are tracked correctly.

Replace any installations of KeyAccess 6.1.3.0 (from 2008-12-01 image) with version 6.1.3.2 or better. (2008-02-01)

Several potentially significant problems with the 6.1.3.0 KeyAccess have been fixed as documented in the component history. While the consequences of the various 6.1.3.0 bugs are obvious from the descriptions, the "Windows client VMware player bug" deserves a further comment: if a Windows computer was upgraded to KeyAccess 6.1.3.0 from a prior version, and that computer has VMware Player installed, a new computer record (id prefixed with V) will be created in the KeyServer's Computers Database. The original record (id prefixed with N) will no longer be associated with any computer, but it will still use up a K2 client license. To clean up, first get rid of the 6.1.3.0 client install (upgrade to 6.1.3.2 or better), and then with KeyConfigure displaying the ID column in the Computers window, delete the faulty "V record" that was created. Note: there is no danger if you delete a "valid" V record corresponding to a virtual computer - the valid record will be recreated the next time the virtual computer is used.

Time synchronization issues when hosting the KeyServer process on a virtual server. (2007-12-01)

The KeyServer process can be run within a virtualized OS environment, but like most services, it does depend on a reliable time clock in order to accurately stamp its data records. Within some virtual environments you may need to take special care to avoid an unstable clock - in particular, time oscillations may result when a virtualized OS and its host OS are both synchronizing with a Network Time Server. Be sure to consult your virtualization product's documentation for additional cautions and for instructions on how to maintain time stability.

New install of Windows KeyAccess 6.1.3.0 will create a service rather than a startup item. (2007-12-01)

The new version 6.1.3.0 of KeyAccess for Windows will install by default as a service, even when upgrading an existing KeyAccess startup application. Unlike previous versions, running KeyAccess as a service is now recommended, whether installing on a standard client (with or without Fast User Switching enabled), or on Windows Terminal Server (with or without Citrix WinFrame, Published Apps, etc.).

Windows KeyAccess 6.1.3.0 required for Vista 64-bit support and when upgrading from XP. (2007-12-01)

The latest KeyAccess client software is required when controlling 64 bit programs under Windows 64-bit editions in order to avoid delays in usage reporting. The newer KeyAccess versions also have the advantage of displaying their user interface in the standard location for a control panel when running in Vista.

KeyAccess must be reinstalled after Windows XP is upgraded to Vista (either the 64-bit or the 32-bit edition). Even though an existing KeyAccess install can appear to continue working after a Vista upgrade, reporting of software usage might have become sluggish due to registry changes. After a Vista upgrade, reinstall using the latest K2Client installer in order to restore the correct interaction between keyacc32.exe and its associated file, katrack.dll.

Windows KeyAccess 6.1.3.0 required to distinguish Acrobat 8 - Standard versus Pro versions. (2007-12-01)

KeyAccess for Windows includes a special case for programs discovered with ACROBAT in the internal property resource - the registry is consulted in order to distinguish Pro from Standard. The KeyServer will create separate records in its Programs database using the distinct identifiers ACROPRO and ACROSTD. Unfortunately, Acrobat version 8 uses a new registry location and therefore the new KeyAccess 6.1.3.0 or better is needed to distinguish Pro 8 from Standard 8. If the distinguishing information is not detected in the registry, the identifier ACROBAT is used (as is the case for older KeyAccess clients). Note: after Acrobat is upgraded from version 7 to version 8 on a computer using an older KeyAccess, the audit will no longer distinguish Pro from Standard (identifying both as ACROBAT). Then an upgrade of KeyAccess to version 6.1.3.0 will redistinguish them using ACROPRO or ACROSTD as appropriate.

KeyConfigure 6.1.3.0 required on Mac OS 10.5 (Leopard) when using the “keyed” option for license control. (2007-12-01)

With the Leopard OS release (Mac OS 10.5), Apple introduced an additional program architecture. Applications included as part of Leopard (such as the various Apple Utilities) make use of this new architecture and will not launch on previous systems. As with any application, these can be controlled by KeyServer according to a license policy specified using KeyConfigure - but if you want to also enable the optional “keyed” behavior, then you must use KeyConfigure 6.1.3.0 or better. If you attempt to key one of these new style applications using an older KeyConfigure, the attempt will appear successful but the resulting modified program will still run (just like its un-keyed counterpart) when KeyAccess is removed !

The new KeyConfigure 6.1.3.0 is also required in order to key any program that is signed using Apple's digital signature interface. KeyConfigure 6.1.3.0 will warn that the signature must be removed when transforming an application into a keyed copy. Note: the keyed version may not function as designed if it relies on any OS service that requires a valid digital signature. Previous KeyConfigure versions just leave the invalidated signature in place when keying - this will typically cause the generation of repetitive warning messages in the console log.

Windows KeyAccess 6.1.2.2 creates new computer record type when installed in VMWare or Parallels. (2007-08-01)

When KeyAccess is run in a “virtual” computer hosted under VMWare or Parallels on a Macintosh, a corresponding record is created in KeyServer's Computers window. Versions of KeyAccess prior to 6.1.2.2 used the virtual ethernet address prefixed by the letter N as the record ID. Beginning with Windows KeyAccess 6.1.2.2, the computer record for a VMWare or Parallels virtual computer will behave just like the Microsoft/Connectix “Virtual PC” case has behaved in previous versions - the virtual network address will be prefixed with the letter V so it is distinguished from computer records for actual computers (which are prefixed by N). Upgrading KeyAccess to the latest version in an existing Parallels or VMWare virtual computer will cause a new computer record to be created (V) and the old record will be abandoned (N). You can use the Duplicate Names (COMP) report to locate any abandoned records - then you should delete them from the Computers window.

Note: When KeyServer first creates a computer record for thin clients (prefix W, L, or T), it classifies the computer as a “Basic client” (no auditing) even if the global default for newly discovered clients is “Full client”. Older KeyServer versions used this same exceptional behavior for virtual clients (prefix V) but beginning with KeyServer 6.1.3.0, new V records follow the specified default discovery rule. In any case, you can over-ride this exceptional discovery behavior (for record types V, W, L, or T) by creating your own explicit rule at the top of the Filters pane in the Computers window. And of course you can always change an existing computer record from its current Login type to Full, Basic, or Prohibited just be dragging onto the desired option.

Windows KeyAccess 6.1.2.0 required to distinguish “Real Player” from “Real Player Helper”. (2007-05-20)

The Real Player application for Windows frequently launches a sub-program, Real Player Helper. Versions of KeyAccess prior to 6.1.2.0 could not distinguish the main program from the helper program. If you want to log or control usage of Real Player, you should make sure Windows clients are upgraded with KeyAccess 6.1.2.0 or better - then configure the Helper program (identified as RPHELPER) to be ignored, while configuring the main program (identified as REALPLAY) to be logged or controlled.

Mac KeyConfigure 6.1.2.0 or better required when keying Adobe CS 3 applications. (2007-05-20)

Any version of KeyConfigure can be used to set up license control for CS 3 applications when using the default option, “unkeyed” control. On Macintosh, KeyConfigure 6.1.2.0 (or better) must be used when transforming the OS X executable files into keyed variants. Product version updaters should only be applied to unkeyed installations. As noted in the Getting Started documentation, some updaters when applied to a keyed executable might remove KeyServer control. Adobe is aware of this issue, so hopefully any new updaters for the CS 3 applications will recognize keyed variants and respond appropriately (and transparently).

Mac KeyAccess 6.1.1.1 fixes KeyCheckout expiration bug (at DST change-over) and other time bugs.(2007-03-15)

Mac KeyAccess 6.1.1.1 or better is required to correct bugs introduced in the 6.0.0.9 and 6.1.0.0 Mac KeyAccess versions that rendered some time related functionality unreliable. When using KeyAccess 6.0.0.9 or 6.1.0.0, portable keys checked out on a Macintosh may expire prematurely. When the time synchronization option is enabled, the Mac KeyAccess 6.1.0.9 version will post a dialog offering to change a client computer's time to an incorrect value (several hours off). This sync bug is fixed by upgrading the KeyAccess client, or it can be avoided by turning KeyServer's time synchronization feature off.

Note: Mac KeyAccess 6.1.0.9 or better is required to provide reliable shadow support for Mac Intel. A byte swap bug prevents KeyAccess versions prior to 6.1.0.9 from correctly locating KeyShadow servers when KeyServer is unreachable.

Location based client access feature requires KeyServer 6.1.0.8 for proper shadow support. (2007-02-01)

Sites using ip ranges to define Locations (for location based control of software access) must use the latest server installer for both KeyServer and KeyShadow processes. A bug in recent KS versions could cause clients to be incorrectly denied service from shadows in case of a network or server failure.

Mac KeyAccess 6.1.0.7 required to report on non-packaged applications on Mac Intel. (2006-11-01)

Applications installed on Mac Intel computers that do not use the Macintosh “Packaged App” format (e.g. MS office 2004) will not be included in the audit data reported by KeyAccess versions prior to 6.1.0.7.

KSdbConsist 6.1.0.6 must be used when upgrading from KeyServer 5.2 to avoid skipping data. (2006-11-01)

Some license management configuration data in the old KeyServer 5.2 format “Active Keys” file is incorrectly treated as corrupt (and is therefore skipped over) by versions of KSdbConsist prior to version 6.1.0.6. When upgrading to 6.1 from KeyServer 5.2, make sure you are using the latest KeyServer installer (which includes the latest KSdbConsist). If you have already used an older version to upgrade from 5.2, inspect your Licenses window to make sure all the configuration information from KeyServer 5.2 has been successfully imported.

ODBC export module 6.1.0.5 required to export with proper character encoding. (2006-10-09)

The ODBC export module has an option for using UTF-8. However, in 6.1 modules prior to version 6.1.0.5, this option did not work as expected. Even when unchecked, text would still be exported as UTF-8 encoded. When checked, text would likewise be exported as UTF-8 encoded, but possibly with erroneous garbage characters. Also in earlier ODBC modules, one column could get created with the wrong SQL type. If you are using the data export feature to mirror KeyServer data onto an external SQL server, first upgrade KeyServer to the latest version (export module 6.1.0.5 or better). Then perform the following steps on your external database to ensure that the data will be re-exported by the new export module:

• DELETE FROM KSdbex where dbexTable='KSComputers'
• DELETE FROM KSdbex where dbexTable='KSPrograms'
• DELETE FROM KSdbex where dbexTable='KSServers'
• DROP TABLE KSServers

KeyAccess 6.1.0.3 required to distinguish Adobe products: Standard versus Pro versions. (2006-08-10)

KeyAccess for Windows includes a special case for programs discovered with ACROBAT in the internal property resource - the registry is consulted in order to distinguish Pro from Standard. The KeyServer will create the identifiers ACROPRO and ACROSTD for these two cases. If the distinguishing information is not detected in the registry, the identifier ACROBAT is used (as is the case for older KeyAccess clients). Note: the identifier distinguishes items in the program window at the “program family”, so the Acrobat Standard and Pro will be in separate line items as soon as you upgrade to the 6.1.0.3 client.

Mac KeyAccess 6.1.0.2 required to support legacy format ppc keyed executables on Mac Intel. (2006-07-14)

Some old format keyed ppc applications will fail to launch on Mac Intel computers using KeyAccess versions prior to 6.1.0.2. You should update Mac Intel computers using the latest K2 client installer. Note: the optional K2Mobile.mpkg installer has also been updated to include KeyCheckout 6.1.0.1 which fixes problems on Mac Intel computers.

KeyServer installers updated with new KSdbConsist 6.1.0.1 data repair utility. (2006-06-20)

The previous KSdbConsist, version 6.1.0.0, incorrectly removed computers from a Group when they were referenced by inclusion of a Division name within the Group specification. Also when KSdbConsist 6.1.0.0 was used to import data from KeyServer version 5.x, some control information would fail to import correctly thus producing an incomplete Licenses database. If KSdbConsist version 6.1.0.0 was used to repair or transform a computers database, use KeyConfigure to check the “fixed.ksr” report and to check the current configuration - make sure that all computer groups remain correctly defined and all license have been correctly imported. It may be best to redo an upgrade from KeyServer 5.2 using the latest installer.

K2 version 6.1 support notes for older client versions.(2006-06-01)

K2 version 6.1 is compatible with 5.x and 6.0 versions of the KeyAccess client but of course old client side bugs will still be present and new features will not be supported. Consult the 6.0 Warnings document and 6.0 Revision history for specific client issues.

K2 6.1 upgrade from K2 6.0 or KeyServer 5.x warnings. (2006-06-01)

Read the Upgrades documentation!

K2 6.1 requires a new license certificate (server.lic) and new KeyConfigure. Before upgrading an older KeyServer version (5.x or 6.0) you must receive a new license certificate configured for 6.1 support - a 6.0 or 5.x certificate will not enable version 6.1.

The major version of KeyConfigure version and KeyServer version must match (e.g. first two digits must match) - KeyConfigure 6.1 won't connect to KeyServer 6.0, KeyConfigure 6.0 won't connect to KeyServer 6.1.

Any KeyShadow installs must be upgraded whenever the KeyServer process is upgraded, and new license certificates must be created using the version 6.1 KeyConfigure.

Upgrade from KeyServer 5.x may require additional clients. 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 loosing 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. 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.

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.