This document is designed to be used alongside the Knowledge Management manual which deals primarily with configuring the knowledge base in order to make the most of the knowledge available. The following information is to be used in order to get a knowledge base built.
Unlike earlier versions of Service Desk, 7.3.2 uses Lucene as the sole knowledge base engine. From an installation point-of-view this is a big advantage as Lucene does not have to be installed separately - it is integrated in to the existing Service Desk components.
The Lucene knowledgebase is built by a task of the Background Processing service. This service chooses where to put the Lucene index folder (the knowledge base) by asking the TPS that it logs into. The TPS stores the location of the Lucene index in a key called 'FreeTextSearchIndexPath' in its tps.config file, if there is no value for this key then the Lucene index will be created in the same location as the tps.config..
In earlier versions of Service Desk it has been recommended to have the Knowledge Base installed on a separate server to the Application, Web and Database servers. While Lucene takes up considerably less space than its predecessor this is still sound advice, particularly if your Users rely heavily on Knowledge. If you do have a separate Knowledge server then installing TPS and Background Processing on that same server should help reduce network traffic and associated potential performance problems.
In addition, there is a further service called the Knowledge Base. The purpose of this service is to move Articles to an expired status when they reach their expiry date and schedule rebuilds of knowledge on a regular basis. It has no function in terms of searching or building knowledge and is only really required if your knowledge base includes articles that will need to be expired.
In earlier versions of Service Desk the location of Verity was stored in the database, when a rebuild or a search was performed the relevant TPS or service could refer to this in order to know where to send the search request or rebuild instruction. The location of the Lucene index is not stored in the database, instead it is stored in the tps.config files. Therefore, each tps.config should have the same path specified for their 'FreeTextSearchIndexPath'.
NOTE: It is completely possible that console and web desk / web access are pointing at different locations. In this instance you might find that console users are able to search knowledge ok but webdesk or self service (7.4+) users are not able to. This is because Console and Web Desk / Web Access use different tps.config files so each of these needs to match. This document shows the default locations for the console and web desk / web access tps config files.
Aside from ensuring that all the client applications know where to search for knowledge the only other configuration required is to ensure that background services is running without errors.
There are a number of diagnostic logging scenarios that can be employed to understand the root cause of an issue affecting Lucene builds.
- Windows Application Event log
If background processing has any problems while it is doing its routine polls it will throw an error to the event log.
- TPS Diagnostic Logging - BackgroundProcessing
This TPS logging of Background Processing can be used to determine if the service is able to find knowledge build requests to process.
- TPS Diagnostic Logging - FreeTextSearch
This TPS logging shows when builds of the Lucene knowledge base are made and whether they were successful.
Lucene is built and is searchable on my Knowledge/Application server but when I do a search from a client connecting through my Web Server I get an error message
This is probably because the Web server doesn't have appropriate permissions to read the Index, in this scenario the Index folder should be available to read to the application pool account that the TPS is running in.
I'm getting different results in Console, Service Portal and Web Desk
This is probably because the tps.config files have different locations specified for the Lucene index. Every tps.config must point at the same location for the index folder. In organisations where it is not possible for External-facing servers to have access to Internal shared folders the Index folder may get copied periodically to the external server(s). This means that knowledge searches carried out on clients of this server will be out-of-date.
Service Portal doesn't show any results
This is can be because the search window isn't configured to include all knowledgeable sources. Click on the configure link at the bottom of that section and make sure that 'Include All Knowledgeable Sources' is checked then save the settings. This can also happen if knowledge is on a network share. The web server may have problems connecting to the share. To resolve this the share should be setup as a null session share.
Lucene builds throw an error - Rebuild index worker thread <number> encountered an error. What do I do?
This message is caused when the User TPS is running as does not have permissions to the Index folder. This is not normally an issue though if the website or application pool TPS is running as have impersonation turned on it can be an issue.
There's a new key in TPS.config called 'TikaFile' and a folder called Tika. What are they for?
Tika is a toolkit used by Lucene to extract the knowledgeable information from documents. You need make no alterations to either the tps.config file nor the folder. The Tika toolkit is only used if you have Active Knowledge and a document library.
If I put the Background Processing Service on my Knowledge Server, do I need to have it on my Application Server too?
No. You should never have more than one instance of Background Processing running against any given Service Desk database at any one time. The Background Processing service can complete all of its tasks from any server it is running from.
What ports are used during a knowledge search?
The communication will be over the standard Windows folder sharing ports (normally NetBIOS ports 135-139) plus you may have to deal with a Kerberos authentication server to allow communication which will require port 88. All the communication is via the standard Windows folder sharing.
I don't want to provide access to an internal server where my Lucene index is built to an externally-facing web server. Is there anything I can do?
Yes. You can make the index folder a hidden share (put a $ on the share name) in order to increase its protection or manually copy the index folder periodically to the web server and point the local tps-configs to that folder. This will mean that the search results will differ from clients searching on the original build.