KCM upgrade

You can upgrade KCM versions 5.5.0 and later to KCM 5.8.0. The upgrade installs KCM 5.8.0 alongside your existing installation, using the same configuration that the current KCM was installed with. The upgrade includes Batch & Output Management.

Before you attempt an upgrade, you need to remove all unconfigured instances. If you have KCM 5.7.0 and above, use InfoKCM.exe to see whether your server has any unconfigured components.

Note the following when upgrading your KCM installation:

  • Before upgrading, back up the databases that the current installation uses.
  • If you have an older KCM installation, first upgrade it to 5.5.0. Then you can upgrade it to 5.8.0.
  • Upgrade will preserve the ports of the Contract Manager and KCM Control Center, but it will re-assign the ports of the KCM instances and of Batch & Output Management. For this, it will use the new start points for private and internal ports.
  • You need to manually reinstall any custom additional language packs. We recommend that you execute the script GetLanguagePack.ps1 of your previous KCM installation prior to upgrading the product, update the custom language packs so they include new translations, and then install the language packs using the tool named AddLanguagePack.exe. For information on managing language packs, see the Manage language packs topic.
  • If your setup in KCM contained a Document Pack Template with at least one exception for a custom Batch & Output Management channel, you need to manually configure this channel after upgrading to KCM 5.8.0 in order for this exception to work. For information on configuring, see the chapter "Configure a project" in the Communications Manager Designer Help.
  • If your B&OM installations share a single KCM/Core installation, after upgrading you need to manually reconfigure KCM/Core to accept remote connections. To access these settings, open KCM/Core Administrator and go to Security section of DP Manager tab.

To upgrade KCM, use a command-line tool Upgrade.exe.

The automated upgrade process performs the following operations:

  1. Exports the configurations of the Contract Manager and KCM instances.
  2. Exports the repository data of the KCM instances and, if available, Batch & Output Management.
  3. Deactivates and stops the current installation.
  4. If the current installation has a Contract Manager, adds a new Contact Manager.
  5. For each KCM instance in the current installation, adds a new KCM instance.
  6. If the current installation has Output Management, adds a new Output Management.
  7. If the current installation has KCM Control Center, adds a new KCM Control Center.
  8. Imports the configurations of the old Contract Manager and the old KCM instances into the new Contract Manager and new instances.
  9. Imports the repository data into the KCM instances and optionally Batch & Output Management.
  10. Transfers the core security configuration from the old KCM instances to the new ones.
  11. Registers the new KCM instances at the new Contract Manager.
  12. Activates and starts the new Contract Manager, new KCM instances, and the new Output Management.

When the upgrade is complete, the new installation becomes active and available for testing. The previously active installation becomes disabled.

The upgrade process copies the KCM Repository content to the new database. Any subsequent changes to the new KCM Repository content are be reflected in the older version.

If the upgrade process encounters an error and the following conditions are met:

  • The error is not in the final step of starting the upgraded instances.
  • The old installation was active before the upgrade.
the upgrade rolls back as follows:

  • Uninstalls the new KCM software .
  • Activates the old KCM installation.
  • Starts the old KCM installation.

This way you can address the reported issue with minimal disruption to the existing installation. You can then try updating again once the issue has been addressed.

If the old installation is not active when an error gets reported by the upgrade, or an error occurs in the final step of starting the upgraded instances, then no automatic rollback is attempted. This makes it possible to investigate the partially installed new software installation, fix the issue, and either rollback, or perform the remaining upgrade steps manually.

Upgrade distributed deployment

When KCM is installed on more than one computer, these should be upgraded in the following order:

  1. On the server that has the Contract Manager installed:
    • When upgrading from KCM 5.6 or lower, create a copy of the \instance-KCMRuntime--[old KCMVersion]\webapps\proxy\tinymce folder.
    • When upgrading from KCM 5.6 or higher, create a copy of the \instance-KCMRuntime--[old KCMVersion]\webapps\proxy\img\current folder.
    • Perform the Contract Manager upgrade.
    • When upgrading from KCM 5.6 or lower, put the \tinymce folder from the previous installation into the \instance-KCMRuntime--[new KCMVersion]\webapps\proxy folder.
    • When upgrading from KCM 5.6 or higher, replace the contents of the \instance-KCMRuntime--[new KCMVersion]\webapps\proxy\img\previous folder with the contents of the \current folder from the previous installation.

    The example web applications of remote instances are not preserved by the Contract Manager upgrade. To recreate the example web applications, restart the remote instances after the Contract Manager upgrade.

  2. Upgrade the servers that have KCM instances installed that connect to this Contract Manager.
  3. Upgrade Batch & Output Management, starting with the primary installation, followed by the secondary installations.

Upgrade requirements

To prepare for the upgrade of a KCM installation on a particular server, you need to do the following:

  1. Create a new database for each KCM instance.
  2. If Batch & Output Management has been installed, create a new repository database and optionally create a runtime database.
  3. Allocate enough disk space to accommodate KCM Repository content .
  4. Make sure the account used to run Upgrade.exe is included in the local Administrators group on the target server.