General requirements

This section describes general requirements that must be satisfied before executing any of the available installation options.

License

You need a valid license to use KCM. When you purchase KCM, you receive either a SAL activation code or a license XML file. The SAL activation code can be used to obtain the API key for the license server access.

When you install KCM, you must provide either the address of the license server in combination with the obtained API key or the license XML file.

The license XML file can restrict the number of allowed document processors. The installers never create more document processors than the maximum allowed.

If after installation more document processors are added, then those additional document processors cannot be started.

if NumberOfDocumentProcessors is 0 in the license XML file, then there is no license maximum on the number of document processors.

Additional information

For MDK Repository Base license, the value for NumberOfUsers must be set to 1.

For development or test purposes, the value for ITP/Server Base license should be "Development and Test". For all other environment elements, the value should be "Development or Test".

Microsoft Word

KCM Core uses Microsoft Word for a number of operations such as printing and conversion of documents. To enable these operations, Microsoft Word must be installed locally on the servers that run KCM Core Document Processors.

You do not need Microsoft Word for conversion to PDF if the conversion is done with the Rendition technology. For more information on this technology, see the section DocToPDF in the Kofax Communications Manager Core Scripting Language Developer's Guide.

You should disable grammar and spelling tools in Microsoft Word. For more information, see the Adjust settings in Microsoft Word section below.

Also, Microsoft Word requires the presence of a Desktop directory. The location of this directory depends on the versions of Microsoft Word and Microsoft Windows. For 64-bit versions of Microsoft Word, create the following directory: %WINDIR%\System32\config\systemprofile\Desktop.

KCM Core attempts to create this directory if it does not exist yet. If it fails, KCM Core is unable to open Microsoft Word documents.

Microsoft Word must be started interactively at least once under the user account used for KCM Core Document Processors. This initializes Microsoft Word for that account so that it can be used by the Document Processors. If this is omitted, certain Core Script calls, such as DocToPDF, may fail.

Adjust settings in Microsoft Word

Open Microsoft Word and check if the following settings are adjusted correctly:

  1. Navigate to File > Options > Display > Printing Options and select Update fields before printing. Click OK.

  2. Navigate to File > Options > Advanced > Save and clear Allow background saves. Click OK.

  3. Navigate to File > Options > Proofing > AutoCorrect Options and clear everything on all tabs. Click OK.

Ports

This section describes the requirements for ports that must be satisfied for successful KCM installation.

When deployed, by defaultKofax Communications Manager uses the following ports. You can configure the installation tool parameters to setup other ports if necessary.

Port Open/Closed

Used by

443

This port is used for external access and should be opened in the firewall.

The main access port for Contract Manager

444

This port is used for external access and should be opened in the firewall.

The KCM Control Center port

10500 and further

These ports should be opened in the internal network of KCM components, but closed for external access.

If all KCM components are installed on the same server, these ports should be closed.

These ports are used for communication between Contract Manager and KCM instances. They are assigned incrementally by KCM, starting from a given fixed point.

  • The registration port of the Contract Manager. This port is used by all instances for automatic (un)registration.
  • The port for KCM ComposerUI for HTML5. There is a separate web application for each instance, but they all use the same port.
  • The port for LogServer to retrieve logs. There is one web application that serves all instances.
  • The port for Resources. There is one web application that serves all instances.
  • The service port for KCM Core. Each instance runs on its own port. This is not a web application.

10600 and further

These ports are internal for KCM. They must be closed for all networks.

The only exception is the repository port. It is used by Designer for Windows to connect to the instance. It must be opened when Designer for Windows is installed.

These ports are assigned incrementally by KCM, starting from a given fixed point.

  • The load balancer port of KCM/Core. Each instance runs on its own port. This is not a web application.
  • The port for KCM Repository Server. Each instance runs on its own port. This is not a web application.
  • The trusted port for KCM Repository Server Each instance runs on its own port. This is not a web application.
  • The port for Rest API. There is one web application that serves all instances.
  • Six ports for Batch & Output Management.

  • The order in which ports are assigned by KCM is not fixed. Use the InfoPorts tool after installation to see which ports were assigned to which (web) application.

  • To prevent a Slow HTTP Denial of Service attack, you should set up your firewall to limit the amount of connections per host for the main access port 443. For example, you can limit the amount to 50 connections per host.

Security

This section describes some decisions you'll have to make during installation regarding the security of communication with KCM server and the artifacts that you have to prepare beforehand.

SSL certificates

All communication with the KCM installation uses HTTPS protocol. KCM Contract Manager and KCM Control Center require a public certificate that must have the external host name of the server in the allowed DNS of its Subject Alternative Name.

Furthermore, most communication within the KCM installation also uses HTTPS protocol. The KCM Server requires an internal certificate that must have the internal (for example, located in the KCM network) host name of the server in the allowed DNS of its Subject Alternative Name.

For both kinds of certificates you must provide a certificate file in a format that is supported by Tomcat (for example, JKS or PKCS12). Additionally, you must ensure that the internal certificates are trusted on their own KCM server, as well on the KCM servers that connect to it (internal connections between the Contract Manager or KCM Control Center and the KCM instances that are registered on it). You can establish the trust by importing the certificate with its trust chain into both the Windows certificate store (with private key on the KCM server, without private key on KCM servers that connect to it) and the Java cacerts trust store (without private key). For the Windows certificate store, use the Personal store of the Local Computer account.

LDAP authentication file

You can set up user authentication at KCM Designer using LDAP.

To set up LDAP authentication, you must provide the LDAP configuration file. See the LDAP properties file topic of this guide for details.

Additional authentication for SOAP calls

You can also set up additional authentication for integrating applications to execute SOAP calls to the Contract Manager. This is possible only after enabling secure connection over SSL.

For more information, see the Applications topic.

(D)DOS attack protection

If it is required to shield the server on which KCM is installed from (D)DOS attacks, you should consider enabling a request rate limiting policy.

KCM does not provide a mechanism for such a policy, so this should be handled by setting up a firewall or proxy server that supports request rate limiting between the KCM installation and the outside network.

Generate self-signed internal certificates

If you find that self-signed certificates are secure enough for internal communication in KCM, then you can have KCM generate the internal certificates.

You must always provide the public certificate yourself.

To generate a self-signed certificate, use the CreateSelfSignedCertificate.exe and ImportSelfSignedCertificate.exe tools, that are located on the top level of the extracted KCM package. You must run these tools before installing KCM.

CreateSelfSignedCertificate.exe

This tool generates a self-signed certificate that can be used as internal certificate on the KCM server where it is generated. It only creates the certificate, but does not yet import it in any certificate store.

This tool has the following parameters:

Parameter Required/Optional Description
Internal!HostName Optional The internal host name of the KCM server. It is set in the Subject Alternative Name of the self-signed certificate. If omitted, KCM uses the COMPUTERNAME environment variable.
InternalCertificate!KeystoreFile Required Location of the generated certificate file. The file may not exist yet.
InternalCertificate!KeystorePassword Required Password of the certificate file. The password should match the requirements of the keytool which might depend on the Java version that you use.
Java!KeytoolExe Required. Location of the keytool.exe file of Java.

ImportSelfSignedCertificate.exe

This tool imports a generated self-signed certificate into both the Java cacerts trust store and the Windows certificate store. You can use it both on the KCM server where the certificate was generated and on a different KCM server where the certificate needs to be trusted.

This tool has the following parameters:

Parameter Required/Optional Description
InternalCertificate!KeystoreFile Required Location of the certificate file.
InternalCertificate!KeystorePassword Required Password of the certificate file.
InternalCertificate!Alias Required Alias of the certificate in the certificate file. The alias is generated (and reported on the console) by the CreateSelfSignedCertificate.exe tool.
Java!KeytoolExe Optional. May be omitted when the JAVA_HOME environment variable has been set and points to a valid Java installation. Location of the keytool.exe file of Java.
Java!TruststoreFile Optional. May be omitted when the JAVA_HOME environment variable has been set and points to a valid Java installation. The location of the Java certificate authorities (cacerts) trust store.
Java!TrustStorePassword Required The password of the Java certificate authorities (cacerts) trust store.

Database

This section describes the requirements for databases that must be satisfied for successful KCM installation.

KCM uses databases to store production data.

  • If you plan to deploy KCM only (without Batch & Output Management), you will need a KCM Repository database.
  • If you also plan to deploy Batch & Output Management, you will need a B&OM Repository database and B&OM Runtime database.

You can find the list of supported databases in the KCM Technical Specifications document.

The deployment does not require a dedicated database server. You can use the database server that is already operating in your environment.

  1. Create all required databases manually.
  2. Before starting the installation, make sure these databases are empty.
  3. Back up all databases on a regular basis and follow the best practices recommended by your database provider.
  4. Unless following specific instructions from Kofax Technical Support, do not make database modifications, because they may cause irreversible damage and loss of data.

KCM performs a check on the database access, using the provided database connection string and database user and password. It checks the database access settings before starting the actual execution of various tools. This check is limited and might erroneously show messages about missing permissions.

To override this check, use the Instance!ContinueInstallationOnFailedDatabaseAccessCheck=true or OutputManagement!ContinueInstallationOnFailedDatabaseAccessCheck=trueparameter to indicate that execution should continue even when the check returns a negative result. This does not override the check on an empty database and partner customer registration.

Adding trusted ServiceAccounts to KCMTools.ini

The KCM installation and upgrade tools verify that the provided user accounts have the Logon as Service right. This preflight check succeeds only if the Logon as Service right is set to the user account directly. When a user account has the Logon as Service as a right via a Group or in any other way, you can disable this check. To do this, use the following steps:

  1. Find the KCMTools.ini file. Before installation or upgrade, this file is located in the Software/KCMTools folder of the extracted KCM 5.8.0 package.

  2. Add a section with name ServiceAccounts.

  3. Add a setting with name Trusted and fill it with a comma-separated list of user accounts that should have the Logon as Service preflight check disabled. Each user account must appear exactly the same as in the command line.