Microsoft Search Server 2010 and Microsoft FAST Search Server 2010 Known Issues/ReadMe

Hardware and Software requirements for Microsoft Search Server 2010:

This content is located on Technet

Hardware and software requirements

SharePoint Search Language Detection

Enterprise search has a language detection feature for which we need to provide copyright attribution.

ICU license - ICU 1.8.1 and later

Original SSLeay License

LIBXML2 License

Manageability:

After changing performance level for the search service via PowerShell, some assert statements "RobotThread tid {num} received no perf obj" may be displayed in displayed in the logs.

Recycle the search service on each box in the farm by entering the following two commands at an elevated prompt:

net stop osearch14

net start osearch14

Automatic Language Detection is by default on after Beta2 upgrade:

By default, the search engine infers the language of documents while crawling to select the right tokenizers (aka. wordbreakers).

Some customers may have turned these off deliberately and want it to remain off (to mimic Search Server 2007 behavior). The RTM release will turn on the language inference system by default on upgrade from Beta2.

Turn off automatic language detection or restart the search service as required (see below). Turning off detection will stop some documents being retrieved, especially html, msg and txt files for some cases.

To turn off language detection, set the following to 0

EnableLanguageDetection

EnableLanguageDetectionPerChunk

within the registry ke:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\
14.0\Search\Global\Gathering Manager

After doing this the search service needs to be restarted, for example using the following commands:

net stop osearch14

net start osearch14

Be sure to set the index server language to the language most common for most of the html, msg and txt files.

After turning off these keys, filtering on language in advanced search will not work for these files either.

Setup:

FAST Search Server configuration fails on Italian Win2k8 SP2 X64:

Post Setup Configuration fails with this error:

Exception -  : Exception - Microsoft.SharePoint.Search.Extended.Installer.Mahasen.Common.Exception.DeploymentException: XML Validation error: L'attributo 'modifiedTime' non è valido. Il valore '2010-04-16T14.35.48Z' non è valido per il tipo di dati 'http://www.w3.org' - La stringa "2010-04-16T14.35.48Z" non è un valore XsdDateTime valido.
   in Microsoft.SharePoint.Search.Extended.Installer.Mahasen.Common.SystemModel.SearchInstallation..ctor(String deploymentXML)

Translated into English:
Exception -: Exception - Microsoft.SharePoint.Search.Extended.Installer.Mahasen.Common.Exception.DeploymentException: XML Validation Error: The attribute 'modifiedTime' is invalid. The value '2010-04-16T14 .35.48 Z 'is invalid for data type' http://www.w3.org '- The string "2010-04-16T14.35.48Z" XsdDateTime is not a valid value.
   in Microsoft.SharePoint.Search.Extended.Installer.Mahasen.Common.SystemModel.SearchInstallation .. ctor (String deploymentXML)

Best workaround is to install Win2k8 R2 instead of Win2k8 SP2

Alternative workaround is to delete the file: C:\FASTSearch\etc\deployment.xsd.

If that file is not found, schema validation will not take place.

FAST Search Center Setup:

Replacing the default FASTSearch certificate with a new certificate using the provided script: ReplaceDefaultCertificate.ps1 fails on Japanese OS.

Workaround:

1. Make a backup of the file.

2. Replace the wrong "-eq" with a new "-eq" and save.

Note: not recommended in production environments as modifying this file breaks future patching of it. It cannot be replaced by a patch later.

Indexer:

Deleting a content collection is not a fault-tolerant operation. If the operation fails on a Backup Indexing Node, the operation will not be reverted on the Master Indexing Node. The result will be that the Master and Backup Indexing Node lose synchronization.

If a Backup Indexing Node fails during the deletion of a content collection, it must be manually synchronized.

Indexer:

Restarting the Indexing Node after an unclean shutdown, the process may appear to freeze for a prolonged time while rebuilding data structures. Depending on the size of the index, rebuilding the data structures may take hours.

Progress is displayed in the Indexing Node log files. The event is preceded by the log message Rebuilding document index. The state of the Indexing Node may also be retrieved using the command line tool indexerinfo. Do not kill the process while the data structures are being rebuilt.

Indexer:

The log messages:

• (WARNING) Filter output failed,

• (ERROR) Could not start file receiver: Signature size mismatch!

• (ERROR) Could not update file

appear on Backup Indexing Nodes.

These log messages may safely be ignored on Backup Indexing Nodes.

Indexer:

Unindexed documents may result from updating the index schema while feeding documents.

Suspend feeding during a schema update, and make sure that the schema change has propagated to both the Document Processing Nodes and the Indexing Nodes before resuming.

Indexer:

The Master Indexing Node does not verify that the Backup Indexing Nodes have enough available disk space.

Before sending data to the Backup Indexing Nodes, the Master Indexing Node will verify that there is enough disk space on the Backup to complete the transfer. If the data being transferred is large, the disk space on the Backup Indexing Node may be filled up by external events during the time the data is transferred. This will lead to the Master and Backup nodes losing synchronization.

Make sure that the Backup Indexing Nodes have at least as much available disk space as the Master Indexing Nodes.

Indexer:

Deleting a content collection is not a fault-tolerant operation. If the operation fails on a Backup Indexing Node, the operation will not be reverted on the Master Indexing Node. The result will be that the Master and Backup Indexing Node lose synchronization.

If a Backup Indexing Node fails during the deletion of a content collection, it must be manually synchronized.

Search Controller:

The Search Nodes are delayed at start-up if the Config Server is unavailable.

The Search Nodes attempt to connect to the Config Server during initialization. Several connection attempts are made, and while log messages claim that the Search Controller will only attempt to connect for a specific amount of time, the time it actually waits is substantially longer.

Start the Config Server, and restart the Search Node.

Feeding:

JDBC Connector does not work with configuration setting Output->OperationMode in the jdbctemplate.xml set to update. The update operation mode is intended for updating a subset of attribute on existing items only, also known as partial updates.

Do not use the operation mode update. For incremental crawls, operation mode add should always be used. Crawling content using the operation mode add requires the all the item attributes to be selected in the JDBCSQL.

Relevance:

If for some reason the web analytics engine loses contact with its worker processes, the processing can be stopped and not restarted automatically. This can typically happen if a machine is rebooted or the network is unstable. The Event Viewer and the FS14 system logs will then contain a log message similar to this:

[2009-12-13 17:15:03] ERROR : webanalyzer@HOSTNAME: systemmsg: Processing failed in makefile "wapartialupdate" for view "default", the view will be set in a stopped state.

Use the waadmin enqueueview command to resume anchortext and link processing. If extra web analytics views have been created, those views may also have to be re-scheduled by running waadmin enqueuview -n<viewname>.

Relevance:

The waadmin option drop_intra is turned on to discard intra-site links, but it doesn't seem to affect the web analytics link analysis.

This option only works if the data source is the FAST Search Web Crawler. It has no effect if the data source is the FAST Search Connector.

Relevance:

The following log message is observed in the Event Viewer or the FS14 system logs and the click-through engine has stopped processing click-through log data:

[2010-01-16 04:00:10.333] WARNING systemmsg Asyncore

callback function raised an exception: <class 'socket.error'>:

(10054, 'Connection reset by peer')

[C:\d\cruise\builds\active\common\sharepointrelevance\src\server\SPUtils.py|asyncore_loop|522]

[C:\d\cruise\builds\active\common\sharepointrelevance\
src\server\SPRelCore.py|Driver|339]

[C:\d\cruise\builds\active\common\sharepointrelevance
\src\server\SPProcEngine.py|scheduler|206]

[C:\d\cruise\builds\active\common\sharepointrelevance\
src\server\SPProcEngine.py|periodic_run_handler|216] [C:\d\cruise\builds\active\common\sharepointrelevance\
src\server\SPProcEngine.py|_startMakefile|260] [C:\d\cruise\builds\active\common\sharepointrelevance\
src\server\SPRunner.py|__init__|52]

[C:\d\cruise\builds\active\common\sharepointrelevance\
src\server\SPRunner.py|__init__|30]

[C:\d\cruise\builds\active\common\sharepointrelevance\
src\server\SPRunner.py|go|56]

[C:\d\cruise\builds\active\common\sharepointrelevance\
src\server\SPRunner.py|run_cidcollapser|72] [C:\d\cruise\builds\active\common\sharepointrelevance\
src\server\SPProcEngine.py|setup|431]

[fdmapi.py|setup|519] [filesys.py|init_filesystem|171] [async_remote.py|run_remote_commands|325]
[async_remote.py|run_ticks|423]
[async_remote.py|profile_callback|386]
[fdmmaster.py|process_from_remote|823]
[fdmmaster.py|disconnect|540]
[utils.py|shutdown|581] [<string>|shutdown|1]

Restart the click-through server with nctrl restart sprel. It runs on the same machine as the web analytics server (WebAnalyzer).

Search Backend:

Floating-point numeric queries on a Text Property may return false hits.

This may happen for Crawled Properties or Managed Properties of data type Text.

For accurate matching on floating point numeric values, use a Managed Property of type Float or Decimal.

Search Backend:

Adding many managed properties to schema over time may lead to high memory usage in the fixmlindex.exe process.

To work around this, either reinstall FAST Search and apply the schema changes in one go, or follow this procedure:

1. Perform all schema updates before starting feeding.

2. Stop the FASTSearchService

3. Remove the file

4. etc\config_data\Schema\webcluster\summaryclasses.xml

5. Start the FASTSearchService

6. Start feed.

Search Backend:

Poor ranking for queries with terms that occur in most documents.

This may happen even on installations with small amounts of documents.

The FAST Search ranking behavior is by default configured to perform performance tradeoffs to ensure good search performance when having large amounts of documents.

The tradeoff reduces how much data needs to be read and processed by the search backend. However, the downside is that more irrelevant documents may be returned and ranked above relevant documents, i.e. precision is reduced.

The tradeoff is done regardless of the number of documents on the node. This is in some cases an advantage as one can then start performing rank tuning even while performing initial feeding, and the ranking behavior will not over time change that much depending on the number of documents.

However, in certain use cases one may want to get the best possible ranking behavior, especially on a small system.

To reduce the effect of this performance tradeoff, you can increase the StopWordThreshold and PositionStopWordThreshold values in the rank profile, as explained in the FAST Search Optimize Relevance documentation.

Search Backend:

Changing the type of a managed property from one numeric type to another numeric type may cause various problems:

In some cases documents that are fed may be discarded from indexing. This may happen when using the indexeradmin resetindex command, or in cases where the system is restarted in an abrupt way.

In other cases, the already fed content may be indexed incorrectly, so that querying using known numeric values may return no results or hits for a wrong set of documents.

A related problem is that deleting and recreating a managed property using the same name and not changing type will cause the content for that managed property to be visible again in the search frontend for all the documents. This may not always be the expected effect.

After changing the data type of a managed property, re-feed the content to ensure the content will be indexed properly.

Search Backend:

When using the FAST Lotus Notes Connector the Get-FASTSearchSecurityUserSecurityFilter does not return any information

Increase the maxStringContentLength from 65536 to 655360 and also change maxArrayLength from 16384 to 163840 in %FASTSEARCH\bin\Microsoft.SharePoint.Search.Extended.
Security.AdminService.exe.config and %FASTSEARCH\bin\Microsoft.SharePoint.Search.Extended.
Security.WorkerService.exe.config

Search Backend:

The Get-FASTSearchSecurityConfigurationStatus comandlet does not work. The Default port is wrong in %FASTSEARCH%\bin\Microsoft.SharePoint.
Search.Extended.Security.Worker.Powershell.
Commands.dll.config.

Open %FASTSEARCH%\bin\Microsoft.SharePoint.Search.
Extended.Security.Worker.Powershell.Commands.dll.config and modify the base_port value from 13000 to 13001.

Search Backend:

Row identifier mismatch between Search Nodes and Indexing Nodes deployed on the same host.

The row identifiers of the Search Nodes are dynamically assigned, while the row identifiers of the Indexing Nodes are decided during installation.

Backup and Restore:

Search is not available after a doing a FAST Search Center configuration restore to a different install directory.

Fix the paths that are no longer valid in %FASTSEARCH%\components\sam\admin\adminTransaction.log.

Follow these steps on the FAST Search Center Admin node to fix the problem:

1. Stop the samadmin process by executing nctrl stop samadmin

1. Edit all file paths in %FASTSEARCH%\components\sam\admin\adminTransaction.log with the correct paths for example if you originally installed FAST Search Center to C:\FASTSearch\ and restored FAST Search Center to E:\FASTSearch then the following entry in your adminTransaction.log:

a5e8d609-9d8f-42b5-bec5-e2ca03f94e66,12/04/2009 14:29:23,NORTHAMERICA\username,AddDomain,ln1,C:\FASTSearch\components\sam\admin\ln1.domain.config.xml

would need to be changed to:

a5e8d609-9d8f-42b5-bec5-e2ca03f94e66,12/04/2009 14:29:23,NORTHAMERICA\username,AddDomain,ln1,E:\FASTSearch\components\sam\admin\ln1.domain.config.xml

1. Start the sam admin process by executing nctrl start samadmin

Backup and Restore:

Search does not work after restoring the FAST Search Center admin node but not restoring the FAST Search Center query node(s)

Move the latest configuration from a FAST Search Center query node to the FAST Search Center admin node by:

1. Stop the samadmin process by executing nctrl stop samadmin

1. Copy all files on a FAST Search Center query node under the %FASTSEARCH%\components\sam\worker to the FAST Search Center admin node under %FASTSEARCH%\components\sam\admin

1. Start the samadmin process by executing nctrl start samadmin

Backup and Restore:

I am running the restore script from the FAST Search Server 2010 for SharePoint distribution in a FAST Search Server 2010 for SharePoint management console. After executing the scripts, all CmdLets loaded with the console are gone.

Due to a bug in the script, the FAST Search Server 2010 for SharePoint unloads the associated PowerShell Snap-In. This can be remediated by executing the command below in the PowerShell prompt:

PS C:\> Add-PsSnapin Microsoft.FASTSearch.PowerShell

Search front-end:

MOSS search site returns the error:

The search request was unable to connect to the Search Service.

when a search is performed right after restarting samworker process. The problem only shows up on the first request through the MOSS front end, after you restart the samworker. The second request and any subsequent requests work.

Make two requests to the MOSS search site after restarting samworker. Ensure search works by checking the result and verifying the second request does not give the error.

Promotions & Demotions:

When adding a promotion/demotion with a URL containing a backslash, queries with the promotion/demotion applied fail.

The promotion/demotion query processing logic doesn't properly escape backslash characters.

This issue should be rarely encountered in practice because the out-of-the-box connector uses proper URLs when feeding content (e.g. file://myserver/mypath).

The recommended workaround is to replace the backslash with a forward slash instead.

E.g. change "\\myserver\mypath" to "//myserver/mypath".

Schema Management:

Enabling the RefinementEnabled setting on a managed property of type Float or Boolean does not work as expected. No refiners are displayed for managed properties of these types.

Workaround:

Use Decimal instead of Float and String instead of Boolean. This means that:

1. ManagedProperty must have Type = Decimal instead of Float and Type = String instead of Boolean.

2. Content source (e.g. Sharepoint List) must use Decimal instead of Float and String instead of Boolean.