Error 43 Failed to communicate with query server

error43Our MOSS 2007 crawls are not completing. In the error logs I get Event ID 43 on the Index Server with the following details:

Event Type: Error
Event Source: Office Server Search
Event Category: Search service
Event ID: 43
Date:
Time:
User: N/A
Computer: Index Server
Description:
Propagation for search application ‘application id’: failed to communicate with query server ‘Web front end Server 1′.

After a long search on the net and trying a lot of different solutions I found the solution of Matt M. I copied the article to SPSTech.net to make sure this useful information is saved.
Situation for the solution:
Customer has 3 MOSS servers (in this example; server 1, 2 and 3).  Server 1 and 2 are front ends and and server 3 is an application server.  Server 1 had the index and query roles.  The wanted to move the index role to server 3 and have a second query role on server 2.
They had been able to move the index role and run a crawl, but that new index would not propagate to either of the query servers.  Matt wrote them an action plan that got them to where they wanted to be.  It might help if you are in a similar situation.
Deactivate Alerts
1. Go to SSP admin > Search settings
2. Search based alerts
3. Deactivate
4. Check the Search alerts status is inactive on the status page. 

Stop the search services on server 1
1. From Central Administration > Services on Server
2. Change the context to server 1
3. Stop the Office SharePoint Server Search
4. Repeat this on server 2 and server 3 – just in case they are running

Delete old Indexes from all servers
1. Just to be tidy: on all servers – go to C:\Program Files\Microsoft Office Servers\12.0\Data\Office Server\Applications
2. Remove index folders (folders named with a GUID) – leave the Applications folder where it is.

Add the Index Role to server server 3
1. From Central Administration > Operations > Services on Server
2. Change the context to server 3
3. From Office SharePoint Server Search click Start
4. Check the box for indexing on this server
5. Use the default index location (will probably be greyed out anyway)
5. Fill in the service account details and start the service.
6. After a few minutes check the index location exists on the file system

Change the index location
1. Go to server 3 console
2. stsadm -o editssp -title YourSharedServicesName -indexserver server 3servername -indexlocation filePathtoIndex
3. After a moment check the new location exists 

Change the SSP
1. Go to Central Admin > Application Management > Create or configure this farm’s shared services
2. Edit properties of SSP (SharedServices1 for example)
3. Go to the index server section and choose server 3 as the new indexer.

Add query role to server 1
1. From Central Administration > Operations > Services on Server
2. Change the context to server 1
3. From Office SharePoint Server Search click Start
4. Start the search service – check the box for querying on this server
5. Fill in the service account details

List search info
1. stsadm -o osearch -action list
2. You should see:
a.  server 3 and server 1 and their roles – check that they are ok at this point
b. Some farm contact info and service account – check these are correct

Just to be sure – set the propagation location
1. On server 1
2. stsadm -o osearch -propagationlocation filePathtoPropagationShare (same as index but on the query server)
3. After a little while you should see the folder shared on the query server file system. 

Run a full crawl
1. From SSP admin > Search settings
2. Select content source and run full crawl
3. Monitor until Idle

Check Propagation to server 1
1. Once the crawl has finished
2. From SSP admin > Search settings
3. Wait for a while and monitor propagation status -
a. Idle – Is good – carry on to Add query role to server 2
b. Propagation Not required – not so good – check the query service is running server 1.  Check the SSP is using server 3 as the index server.
c. Propagating to New Query server – might need attention if it stays like that for too long – give it 5 minutes.  Check the application event log for 6398 and 6482.

If propagation doesn’t work we are into troubleshooting mode.  Things to check:
a. The index location exists on the server 1
b. Its shared as searchindexpropagation
c. The share permissions include the WSS_WPG_ADMIN group and it has full control
d. The WSS_WPG_ADMIN group has full control on the Security tab as well
e. Events on server 3 – like can’t propagate, no access to share, shared doesn’t exist etc. Also 6398, 6482
If Propagation seems to work OK – got to a web app and run a search query

Add query role to server 2
1. If we see propagation working ok from server 3 to server 1 we start search on server 2
2. From Central Administration > Services on Server
3. Change the context to server 2
4. Start the search service – check the box for querying on this server
5. Fill in the service account details
Just to be sure – set the propagation location
1. On server 2
2. stsadm -o osearch -propagationlocation filePathtoPropagationShare (same as index but on the query server)
3. After a little while you should see the folder shared on the query server file system. 

Check Propagation to server 2
1. From SSP admin
2. Search settings
3. Monitor propagation status -
a. Idle – Is good
b. Propagation Not required – not so good
c. Propagating to New Query server – might need attention if it stays like that for too long – give it 5 minutes.

Activate Alerts
When everything is working as expected
1. Go to SSP admin > Search settings
2. Search based alerts
3. Activate
4. Check the Search alerts status is active on the status page.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">