Limitations — Administration

This section contains the following:

Limitations — General


Limitations — Mixed-Version and Multiple K2 Domains


Limitations — General

Cannot change alias names

Once a K2 object is created (such as a collection, service, parametric index, and so on) you cannot change its alias.

Workaround: Remove the object from the K2 system and create an identical object with the new alias name.

On Solaris, communication of K2 Server status is delayed

On Solaris, when a K2 Broker tries to connect to a K2 Server that has been unplugged from the network, it takes approximately three minutes before the connect call fails. This delays the K2 Broker in its receiving K2 Server status information. When you use the command rck2 -i to get information in this scenario, the process will hang. (85135) (79134)

K2 Ticket Server running the NT login module using an Active Directory domain

With this configuration, getgroup error -1205 can be displayed for some users. The user making the calls to obtain groups has to be part of the “Pre-Windows 2000 compatible access” group.

If you call this function on a domain controller that is running Active Directory, access is allowed or denied based on the access control list (ACL) for the securable object. The default ACL permits all authenticated users and members of the Pre-Windows 2000 Compatible Access group to view the information. By default, this group includes “Everyone” as a member. This enables anonymous access to the information if the system allows anonymous access. (69615)

Workaround: From an Active Directory domain controller, navigate to Programs | Administrative Tools, and run the Active Directory Users and Computers program. In the left window there is a listing for your domain. Click on the Builtin listing under your domain name. Double-click on the Pre-Windows 2000 Compatible Access group on the right hand window. Under the Members tab click the Add button, and add the Domain Users group.

K2 Administration may not wait long enough for processes to finish

When K2 Administration launches processes such as mkvdk for collection purging, or k2spider_srv for starting indexing jobs, it waits a configured length of time for the process to start or finish. If the process does not start or finish within that time period, K2 Administration assumes the process has failed, and shuts it down. The default time limit is one minute, and is usually sufficient. However, for collection purging, a longer time limit may be necessary. (90847, 90868)

Workaround: To increase the length of time K2 Administration waits for a process to complete before assuming the process has failed, set the environment variable VERITY_ADMIN_SPIDER_LAUNCH_TIME . The environment variable value must be in seconds and greater than 60. We recommend a value of 300 seconds (5 minutes) for an mkvdk collection purge.

Limitations — Mixed-Version and Multiple K2 Domains

If you name the K2 domains in a multi-domain K2 system, mirrored collections must exist in the same K2 domain

If you are setting up mirrored indexes across K2 domains, the K2 domains should not be named. In this case, all K2 Ticket, K2 Broker, and K2 Server aliases must be unique across all the K2 domains.


Note   In mixed-version systems, all K2 Server, K2 Broker, and K2 Ticket Server aliases must be unique across V6.0, V5.5, V5.0, V4.5.1, and V4.0.3, regardless of whether the K2 domains are named.


In a mixed-version K2 system, recommendation and profiling are not supported

When a V6.0 K2 Broker has a V4.5.x (or earlier) K2 Server or K2 Broker attached, then recommendation and profiling in the V4.5 system are not supported from the V6.0 K2 Broker.

In a mixed-version K2 system, document-level security is not supported for collections and knowledge trees in V4.0.3 K2 domains

A V4.0.3 K2 Ticket Server cannot be present in a mixed-version environment and a V4.5.1, V5.0, V5.5, or V6.0 K2 Ticket Server cannot be attached to V4.0.3 K2 Brokers and K2 Servers. This constraint means that document-level security is not supported in V4.0.3 K2 domains of a mixed-version K2 search system.

Secure documents within the V4.0.3 K2 domain will not return search results when queried from the V6.0 K2 Broker. For file system gateway collections, varying results can be expected.

Workaround: Perform the search from within the V4.0.3 K2 domain. (Gateway security is not applicable to V6.0 systems.)

In a mixed-version K2 system, server aliases are required in the V4.0.3 system

K2 Server and K2 Broker aliases were not required in V2.2.0 or V4.0.3 systems. However, in a mixed-version environment, K2 Server aliases are required to be defined in the V4.0.3 INI files, due to the new K2 Server and K2 Broker synchronization process. The reference aliases in the V6.0 K2 Broker must match aliases named in the K2 Server and K2 Broker INI files. For V6.0, the K2 Server and K2 Broker aliases can still be empty or arbitrary in the INI files.

Additionally, each alias name must be unique across the entire mixed-version search system.

If the aliases are not correct, the V6.0 K2 Broker will have problems updating information from V4.0.3 K2 Servers. For example, if a collection is set online or offline, the K2 Broker will not recognize the change. As another example, when a V4.0.3 K2 Server shuts down and starts up, that K2 Server will not be recognized by the K2 Broker, resulting in the K2 Server collections no longer being searchable.

In a mixed-version K2 system, some methods cannot be used to view documents

If you have a mixed-version K2 system, with a V4.0.3 K2 service attached to a V6.0 K2 domain, documents in the V4.0.3 system cannot be viewed from the V6.0 system through the following methods:

rck2 vv


the K2 Dashboard's Test Search function