Unknown's avatar

Posts by Simon Doy

I am an avid SharePoint enthusiast who works as an Independent SharePoint Consultant based in Leeds, United Kingdom. I am one of the organisers of the Yorkshire SharePoint User Group in the United Kingdom. I have been designing and building SharePoint solutions since 2006.

>A word breaker was not found for the given language error when crawling content.


>The problem:
When a search crawl occurs an error is put in the crawl log.

“A word breaker was not found for the given language. Check your current language settings and ensure that search supports the current language. If the problem persists, reinstall search.”

The fix can be found here:-
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3186952&SiteID=1

Ah well found the fix and will document it here in case anyone else has a problem.

So the word breaker files are all found in the registry here:-

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Setup\ContentIndexCommon\LanguageResources\Default

Under the registry key for each of the languages there is a value called

StemmerDLLPath and WBDLLPathOverride

For the English (United Kingdom) and English (United Status) languages these values were set to the following 8-3 path names:

C:\PROGRA~1\MICROS~2\12.0\Bin\NATURA~1.DLL

So at the command prompt I typed in the following:-

dir /x C:\PROGRA~1\MICROS~2\12.0\Bin

Guess what the following line appeared:-

07/04/2008 13:27 3,976,520 NATURA~2.DLL naturallanguage6.dll

So updated the registry entry with NATURA~1.dll to NATURA~2.dll and restarted the Office and Windows Search. Performed a Full Crawl and finally a number of successful crawls entered the crawl logs.

Hurrah!

This dll seems to handle a number of Languages including French, German, Dutch, Hebrew, Spanish and Italian.

Basically this issue happened on our QA environment when we were doing some testing. We racked our brains as to what changes have been made and couldnt think of a reason. Then after the problem was fixed we realised that the machine has been restored using TrueImage and this must have been the cause of the change in 8-3 filename!

>Upgrading SharePoint to SP1


>I have a number of development environments for different clients. Anyway I started some work for myself on one of the old machines and thought I better get this up to date and install WSS SP1 and MOSS SP1.

Simple .. Yeah!? I should have checked things out on the machine before I started. I have performed the upgrade on a number of machines with no problems. However there this time I did the normal install WSS v3 SP1 and then run the SharePoint Config Wizard… the wizard ran and then throw an error. I clicked on the link and it showed an error trying to start the Office Search.

I check the Office Search and yes it was unable to login. I went into services and updated the account name and password. Re ran the wizard and it failed again, this time resetting the account back the previous account. SharePoint holds this setting and reapplies the account details so using stsadm -o osearch -action start I applied the new farmaccount and password. This fixed the Office Search service which started successfully.

Reran the wizard to perform the upgrade and it failed again.
Looking at the psconfig logs showed that there was now a problem with the SharePoint WSS Search. I used stsadm -o spsearch -action stop to clean things up and then ran stsadm -o spsearch -action start using the new account and password credentials. It complained about the database not being empty. So after deleting the database, the command was run again.

Each time this was run an error happened saying that the search could not be started due to invalid login. I thought well I will try the upgrade and see what happens. Again the upgrade failed.

Looking on the web I found a link to http://geekswithblogs.net/hinshelm/archive/2007/12/13/installing-windows-sharepoint-services-3.0-service-pack-1-sp1.aspx

Where people were having similar issues this lead me to the idea of running the upgrade process using psconfig.

So going on to the command prompt I ran psconfig -cmd upgrade -inplace b2b this failed and required that the force flag is set because the upgrade has failed.

Run psconfig -cmd upgrade -inplace b2b -force, still the upgrade failed though looking into the upgrade.log file which lives in the HIVE12\logs. In the logs the same error about the SPSearch showed which said that the login was invalid. I started to think that this might be down to the fact that SP1 has been applied but the search process is unable to login due to issues with fact that the binaries are expecting an upgraded database but this hasnt occured yet.

From this thought I decided to stop the SPSearch and then do the upgrade:-
– doing an stsadm -o spsearch -action stop this when run asks if you want to delete all the indexes, say yes.

Then re-ran the psconfig -cmd upgrade -inplace b2b -force command.
After a while the command completed successfully! Hurrah.

Now to sort out the SPSearch function, this was solved by running stsadm -o spsearch -action start -farmserviceaccount [account] -farmservicepassword [password]

The SPSearch started successfully!

Anyway I hope that will help someone.